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

David M. Lloyd david.lloyd at redhat.com
Thu Nov 6 11:28:04 EST 2008


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



More information about the jboss-development mailing list