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

[Paul Gier]

Can you clarify a bit what you are asking for?
The maven standard for source jars is just to append "-sources" to the name.  So 
things like the dependency plugin and m2eclipse use that convention to find 
sources that are associated with a particular jar.

Max Rydahl Andersen wrote:
> 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
> 
> 
>