[jboss-dev] jbossall-client.jar now references external libs

[Max Rydahl Andersen]

Note, client api is one thing; the other is server side API and being able  
to figure out
which source jar goes with which runtime jar in JBoss AS. Having pom info  
for that would
be good...is that doable ?

/max

> Since there seems to be a lot of demand for this, I'm going to create a  
> new directory in the app server called "client".  And this will contain  
> a pom that lists all the jars that are currently in the all-client jar  
> manifest.
>
> This will be deployed to our repository with the release, so it should  
> be usable from maven or ivy.
>
> Max Rydahl Andersen wrote:
>> This is what should be done; have a proper managed repository of jars
>> that is usable from both Maven and Ivy. Then *a lot* of issues from a
>> tooling perspective would be way easier to solve.
>>  /max
>>
>>> If we produced a proper jbossall-client artifact in the maven
>>> repository, i.e. one that specified all its dependencies (the other
>>> client jars).
>>> http://repository.jboss.com/maven2/org/jboss/client/jbossall-client/5.0.0.Beta4/jbossall-client-5.0.0.Beta4.pom  
>>> NOTE: The one above comes from before the change to use the manifest.
>>>
>>> At least people using maven could create their .classpath correctly.
>>>
>>> Another option would be to include a dummy eclipse project
>>> in the distribution that people could import into their project.
>>>
>>> On Thu, 2008-11-06 at 10:28 -0600, David M. Lloyd wrote:
>>>> Are there mechanisms which Eclipse *will* read?  Like OSGi  
>>>> descriptors or
>>>> something like that?  Do we have an Eclipse plugin for
>>>> jboss-classloading.xml support yet? :-)
>>>>
>>>> - DML
>>>>
>>>> On 11/06/2008 09:56 AM, Sacha Labourey wrote:
>>>> > I agree, this will be a big usability issue. For the sake of making  
>>>> OUR life
>>>> > easier (patching), we are going to make EVERYBODY's life more  
>>>> difficult,
>>>> > that's nonsense. If you need a patching mechanism, write a script  
>>>> which will
>>>> > just do that, but do not impact user usability.
>>>> >
>>>> >> -----Original Message-----
>>>> >> From: jboss-development-bounces at lists.jboss.org [mailto:jboss-
>>>> >> development-bounces at lists.jboss.org] On Behalf Of Galder Zamarreno
>>>> >> Sent: jeudi, 6 novembre 2008 16:48
>>>> >> To: JBoss.org development list
>>>> >> Subject: Re: [jboss-dev] jbossall-client.jar now references  
>>>> external
>>>> >> libs
>>>> >>
>>>> >> Hmmmm, we're gonna have users screaming about this.
>>>> >>
>>>> >> In the past, if you're developing a client app in Eclipse, you only
>>>> >> needed jbossall-client.jar and log4j.jar but this won't be the case
>>>> >> with
>>>> >> AS5 as I've just found out when trying to run a client app against
>>>> >> trunk. Eclipse for example does not read manifest classpath  
>>>> entries:
>>>> >>
>>>> >> http://forums.bea.com/thread.jspa?threadID=570001075
>>>> >>
>>>> >> I've just talked to Max who confirmed it. I'll let him explain the  
>>>> gory
>>>> >> details of Eclipse.
>>>> >>
>>>> >> Cheers,
>>>> >>
>>>> >> Dimitris Andreadis wrote:
>>>> >>> Yes, they'll need the whole jboss/client dir.
>>>> >>>
>>>> >>> Max Rydahl Andersen wrote:
>>>> >>>> I'm curious how this affects users (and hence tooling).
>>>> >>>>
>>>> >>>> I assume users now instead of having jbossall-client.jar on the
>>>> >>>> classpath will need to have an exact
>>>> >>>> copy of client/*.jar etc. when running against jboss ?
>>>> >>>>
>>>> >>>> /max
>>>> >>>>
>>>> >>>>> Paul changed jbossall-client.jar so now instead of embedding the
>>>> >>>>> content of the other client
>>>> >>>>> libraries, it now references them through MANIFEST.MF Class-Path
>>>> >> entry.
>>>> >>>>> This makes it possible to introduce drop-in replacements for  
>>>> client
>>>> >>>>> libs, if needed, without
>>>> >>>>> worrying about jbossall-client.jar
>>>> >>>>>
>>>> >>>>> http://jira.jboss.com/jira/browse/JBAS-4355
>>>> >>>>> _______________________________________________
>>>> >>>>> jboss-development mailing list
>>>> >>>>> jboss-development at lists.jboss.org
>>>> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> jboss-development mailing list
>>>> >>>> jboss-development at lists.jboss.org
>>>> >>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >>> _______________________________________________
>>>> >>> jboss-development mailing list
>>>> >>> jboss-development at lists.jboss.org
>>>> >>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >> --
>>>> >> Galder Zamarreño
>>>> >> Sr. Software Maintenance Engineer
>>>> >> JBoss, a division of Red Hat
>>>> >> _______________________________________________
>>>> >> jboss-development mailing list
>>>> >> jboss-development at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > jboss-development mailing list
>>>> > jboss-development at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development



-- 
/max