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

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