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

Paul Gier pgier at redhat.com
Tue Nov 18 11:30:56 EST 2008


Yes, it is in the appropriate maven repository under a unique groupId/artifactId 
at the URL that I originally posted [1].

Users would access it from the maven repository, not from the svn repository.

[1]http://snapshots.jboss.org/maven2/org/jboss/jbossas/jboss-as-client/5.0.0-SNAPSHOT/

Max Rydahl Andersen wrote:
> 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
> 
> 
> 




More information about the jboss-development mailing list