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