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

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.... > > 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(a)redhat.com&gt; > 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... > >>>>>>> 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(a)lists.jboss.org > [mailto:jboss- > >>>>>>>> >> development-bounces(a)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(a)lists.jboss.org > >>>>>>>> >>>>> > https://lists.jboss.org/mailman/listinfo/jboss-development > >>>>>>>> >>>>> > >>>>>>>> >>>> > >>>>>>>> >>>> > >>>>>>>> >>>> _______________________________________________ > >>>>>>>> >>>> jboss-development mailing list > >>>>>>>> >>>> jboss-development(a)lists.jboss.org > >>>>>>>> >>>> https://lists.jboss.org/mailman/listinfo/jboss-development > >>>>>>>> >>> _______________________________________________ > >>>>>>>> >>> jboss-development mailing list > >>>>>>>> >>> jboss-development(a)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(a)lists.jboss.org > >>>>>>>> >> https://lists.jboss.org/mailman/listinfo/jboss-development > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > _______________________________________________ > >>>>>>>> > jboss-development mailing list > >>>>>>>> > jboss-development(a)lists.jboss.org > >>>>>>>> > https://lists.jboss.org/mailman/listinfo/jboss-development > >>>>>>>> _______________________________________________ > >>>>>>>> jboss-development mailing list > >>>>>>>> jboss-development(a)lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> jboss-development mailing list > >>>>> jboss-development(a)lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development > >>>> > >>> > >>> _______________________________________________ > >>> jboss-development mailing list > >>> jboss-development(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/jboss-development > >> > > > > _______________________________________________ > > jboss-development mailing list > > jboss-development(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/jboss-development > > >