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