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

[Max Rydahl Andersen]

On Thu, 06 Nov 2008 17:28:04 +0100, David M. Lloyd  
<david.lloyd at redhat.com> wrote:

> Are there mechanisms which Eclipse *will* read?

Does intellij read the manifest.mf and use it at compile time ?

>  Like OSGi descriptors or something like that?

yes, but they got logical names which is different than physical artifact  
names as stated in manifest.mf's.

> Do we have an Eclipse plugin for jboss-classloading.xml support yet? :-)

Did you submit a request/patch for JBoss Tools detailing what you  
need/want yet ?

/max

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



-- 
/max