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

[Galder Zamarreno]

It's not even in the generated AS server, only in the source repo.

Max Rydahl Andersen wrote:
> if it is not in the EAP it does not exist for users hence non-supported ;)
> 
> /max
> 
>> The pom is here: https://svn.jboss.org/repos/jbossas/trunk/client/
>>
>> Galder Zamarreno wrote:
>>> Hmmm, strange because I built trunk on Friday and I see no .pom 
>>> whatsoever in the client/ directory. Am I missing something?
>>>  Paul Gier wrote:
>>>> It's in the client directory.  And it's in the maven snapshot 
>>>> repository:
>>>> http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-client/5.0.0-SNAPSHOT/ 
>>>> Galder Zamarreno wrote:
>>>>> 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.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
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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