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

[Galder Zamarreno]

I was naively expecting that the client pom would be something that not 
only was available in the source repo, but would be added to the build 
output under client/ directory as in [JBOSS_HOME]/client.

Paul Gier wrote:
> 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