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

Adrian Brock abrock at redhat.com
Mon Nov 10 11:34:46 EST 2008 

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.

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
> 
> 
> 
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

More information about the jboss-development mailing list