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

> 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.

/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