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

[Paul Gier]

We currently have just one source jar files for each app server module.  So for 
example in the maven repository [1], the j2se module has one jar for all the 
main class files, one for all the main sources, and a few jars that include a 
subset of the classes.

[1] http://repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-j2se/5.0.0.CR2/

Max Rydahl Andersen wrote:
> On Mon, 10 Nov 2008 15:27:30 +0100, Paul Gier <pgier at redhat.com> wrote:
> 
>> 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.
> 
> I'm asking if we have that for *every* jar in AS so we could use it when
> setting up a server in Eclipse ?
> 
> /max
> 
>> 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
>>>
>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
> 
>