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

On Mon, 10 Nov 2008 17:34:46 +0100, Adrian Brock <abrock(a)redhat.com&gt; 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.... >> >> >> 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(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 >> >> >>