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

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