[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