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

Paul Gier pgier at redhat.com
Tue Nov 18 12:09:15 EST 2008 

For adding the client dependencies to a pom it should just look something like this:

<dependency>
   <groupId>org.jboss.jbossas</groupId>
   <artifactId>jboss-as-client</artifactId>
   <version>5.0-SNAPSHOT</version>
   <type>pom</type>
</dependency>

If I have time this week I'll try to create a more complete example.

Galder Zamarreno wrote:
> Ah, I see your point now. Towards GA, I suppose a wiki or some 
> documentation with a skeleton pom.xml with such dependency would help 
> users work out what they need to add to their poms to get such pom.xml.
> 
> This is at least step forward because people can then generate IDE 
> classpaths of that.
> 
> Paul Gier wrote:
>> 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
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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