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

[Paul Gier]

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.Beta4/jbossall-client-5.0.0.Beta4.pom 
>>>
>>>
>>> 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 at lists.jboss.org [mailto:jboss-
>>>> >> development-bounces at 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 at lists.jboss.org
>>>> >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >>>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> jboss-development mailing list
>>>> >>>> jboss-development at lists.jboss.org
>>>> >>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >>> _______________________________________________
>>>> >>> jboss-development mailing list
>>>> >>> jboss-development at 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 at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > jboss-development mailing list
>>>> > jboss-development at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>>
>>
> 
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development