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
--
Galder ZamarreƱo
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat