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.
[
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...
>>>>>> 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...
>>>>>>>>>>> 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(a)lists.jboss.org
>>>>>>>>>>>> [mailto:jboss-
>>>>>>>>>>>> >>
development-bounces(a)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(a)lists.jboss.org
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>>>
_______________________________________________
>>>>>>>>>>>> >>>> jboss-development
mailing list
>>>>>>>>>>>> >>>>
jboss-development(a)lists.jboss.org
>>>>>>>>>>>> >>>>
>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>>> >>>
_______________________________________________
>>>>>>>>>>>> >>> jboss-development mailing
list
>>>>>>>>>>>> >>>
jboss-development(a)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(a)lists.jboss.org
>>>>>>>>>>>> >>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> >
_______________________________________________
>>>>>>>>>>>> > jboss-development mailing list
>>>>>>>>>>>> > jboss-development(a)lists.jboss.org
>>>>>>>>>>>> >
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>> jboss-development mailing list
>>>>>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-development mailing list
>>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jboss-development mailing list
>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>
>
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development