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

Tue Nov 11 03:16:50 EST 2008

On Mon, 10 Nov 2008 17:34:46 +0100, Adrian Brock <abrock at redhat.com> wrote:

> On Mon, 2008-11-10 at 17:31 +0100, Max Rydahl Andersen wrote:
>> > 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/
>>
>> What i'm missing is a map from AS's jar's to their relevant  
>> -sources/-docs
>> artifact
>> so we can map them to the apropriate -sources.jar in eclipse.
>>
>
> For the sources, run:
>
> mvn dependency:sources eclipse:eclipse
>
> This will download the source jars into your maven repository
> then create a .classpath file that references them.

That gives me a .classpath for *building* AS based on the local maven  
repository
...what I need is a classpath/source/javadoc map for the jars inside AS  
when it is being *used*

/max

> I imagine there is something similar for javadocs???
>
>> /max
>>
>> > 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
>> >>
>> >
>> > _______________________________________________
>> > jboss-development mailing list
>> > jboss-development at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>>


-- 
/max