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

Where is this client pom? Paul Gier wrote: > I added a new client pom if anyone wants to try it. There are still > some things I need to work out, because a few of the jars were not > available in the maven repo and it's including a lot of trasitive jars > that probably need to be excluded. > > Paul Gier wrote: >> 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