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

Max Rydahl Andersen max.andersen at redhat.com
Tue Nov 18 11:08:05 EST 2008 

some trunk svn location is not something you give to a user/customer to  
use from maven...

Shouldn't it be in the apropriate maven repository under some unique  
artifact id ?

/max

> I would expect people to use it in a build in a similar way that most  
> maven poms are used.  So you would need to access it in the repository  
> using maven or ivy.   For either of these it would just be a matter of  
> adding the dependency to the build.  If you need an example, I can try  
> to put one together.
>
>
> Galder Zamarreno wrote:
>> Paul,
>>  How do you expect people to use that client pom.xml? Have some kind of  
>> remote dependency on that client pom.xml once it's up in the maven  
>> repository or retrieve it from the source repo? If you want people to  
>> try it out, we could do with some clearer guidance on how to use it.
>>  Cheers,
>>  Galder Zamarreno wrote:
>>> 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
>>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development



-- 
/max

More information about the jboss-development mailing list