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

Is there going to be a maven2 pom for the jbossall-client.jar that references all dependent jars that are in the manifest class-path? The 5.0.0.beta4 one currently does not. Aaron On 12/06/2008, at 1:28 AM, 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 _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

-----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

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

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

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

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

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

if it is not in the EAP it does not exist for users hence non-supported ;) /max > 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

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

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

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

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

Can you clarify a bit what you are asking for? The maven standard for source jars is just to append "-sources" to the name. So things like the dependency plugin and m2eclipse use that convention to find sources that are associated with a particular jar.

Max Rydahl Andersen wrote: > Note, client api is one thing; the other is server side API and being > able to figure out > which source jar goes with which runtime jar in JBoss AS. Having pom > info for that would > be good...is that doable ? > /max > >> 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

We currently have just one source jar files for each app server module. So for example in the maven repository [1], the j2se module has one jar for all the main class files, one for all the main sources, and a few jars that include a subset of the classes. [1] http://repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-j2se/5.0.0....

Max Rydahl Andersen wrote: > On Mon, 10 Nov 2008 15:27:30 +0100, Paul Gier <pgier(a)redhat.com&gt; wrote: > >> Can you clarify a bit what you are asking for? >> The maven standard for source jars is just to append "-sources" to the >> name. So things like the dependency plugin and m2eclipse use that >> convention to find sources that are associated with a particular jar. > I'm asking if we have that for *every* jar in AS so we could use it > when > setting up a server in Eclipse ? > /max > >> Max Rydahl Andersen wrote: >>> Note, client api is one thing; the other is server side API and being >>> able to figure out >>> which source jar goes with which runtime jar in JBoss AS. Having pom >>> info for that would >>> be good...is that doable ? >>> /max >>> >>>> 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

On Mon, 2008-11-10 at 17:31 +0100, Max Rydahl Andersen wrote: > > We currently have just one source jar files for each app server > module. > > So for example in the maven repository [1], the j2se module has one > jar > > for all the main class files, one for all the main sources, and a few > > jars that include a subset of the classes. > > > > [1] > > > http://repository.jboss.org/maven2/org/jboss/jbossas/jboss-as-j2se/5.0.0.... > > What i'm missing is a map from AS's jar's to their relevant > -sources/-docs > artifact > so we can map them to the apropriate -sources.jar in eclipse. > For the sources, run: mvn dependency:sources eclipse:eclipse This will download the source jars into your maven repository then create a .classpath file that references them.

I imagine there is something similar for javadocs??? > /max > > > Max Rydahl Andersen wrote: > >> On Mon, 10 Nov 2008 15:27:30 +0100, Paul Gier <pgier(a)redhat.com&gt; > wrote: > >> > >>> Can you clarify a bit what you are asking for? > >>> The maven standard for source jars is just to append "-sources" to > the > >>> name. So things like the dependency plugin and m2eclipse use that > >>> convention to find sources that are associated with a particular > jar. > >> I'm asking if we have that for *every* jar in AS so we could use it > >> when > >> setting up a server in Eclipse ? > >> /max > >> > >>> Max Rydahl Andersen wrote: > >>>> Note, client api is one thing; the other is server side API and > being > >>>> able to figure out > >>>> which source jar goes with which runtime jar in JBoss AS. Having > pom > >>>> info for that would > >>>> be good...is that doable ? > >>>> /max > >>>> > >>>>> 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 > > >

>> For the sources, run: >> >> mvn dependency:sources eclipse:eclipse >> >> This will download the source jars into your maven repository >> then create a .classpath file that references them. > That gives me a .classpath for *building* AS based on the local maven > repository > ...what I need is a classpath/source/javadoc map for the jars inside AS > when it is being *used* A *-source.jar for each of these jars in client/, do we have such thing? We probably have some but not all. I think that's what Max' asking.

file:///home/galder/access/as-rel/trunk/client/xmlsec.jar file:///home/galder/access/as-rel/trunk/client/wstx.jar file:///home/galder/access/as-rel/trunk/client/wsdl4j.jar file:///home/galder/access/as-rel/trunk/client/trove.jar file:///home/galder/access/as-rel/trunk/client/streambuffer.jar file:///home/galder/access/as-rel/trunk/client/stax-ex.jar file:///home/galder/access/as-rel/trunk/client/stax-api.jar file:///home/galder/access/as-rel/trunk/client/slf4j-jboss-logging.jar file:///home/galder/access/as-rel/trunk/client/slf4j-api.jar file:///home/galder/access/as-rel/trunk/client/scout.jar file:///home/galder/access/as-rel/trunk/client/policy.jar file:///home/galder/access/as-rel/trunk/client/mail.jar file:///home/galder/access/as-rel/trunk/client/logkit.jar file:///home/galder/access/as-rel/trunk/client/log4j.jar file:///home/galder/access/as-rel/trunk/client/jnp-client.jar file:///home/galder/access/as-rel/trunk/client/jmx-invoker-adaptor-client.jar file:///home/galder/access/as-rel/trunk/client/jmx-client.jar file:///home/galder/access/as-rel/trunk/client/jettison.jar file:///home/galder/access/as-rel/trunk/client/jbossws-spi.jar file:///home/galder/access/as-rel/trunk/client/jbossws-native-saaj.jar file:///home/galder/access/as-rel/trunk/client/jbossws-native-jaxws.jar file:///home/galder/access/as-rel/trunk/client/jbossws-native-jaxws-ext.jar file:///home/galder/access/as-rel/trunk/client/jbossws-native-jaxrpc.jar file:///home/galder/access/as-rel/trunk/client/jbossws-native-core.jar file:///home/galder/access/as-rel/trunk/client/jbossws-native-client.jar file:///home/galder/access/as-rel/trunk/client/jbossws-jboss50.jar file:///home/galder/access/as-rel/trunk/client/jbossws-framework.jar file:///home/galder/access/as-rel/trunk/client/jbossws-common.jar file:///home/galder/access/as-rel/trunk/client/jbosssx-client.jar file:///home/galder/access/as-rel/trunk/client/jbosssx-as-client.jar file:///home/galder/access/as-rel/trunk/client/jbossjmx-ant.jar file:///home/galder/access/as-rel/trunk/client/jbosscx-client.jar file:///home/galder/access/as-rel/trunk/client/jbossall-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-xml-binding.jar file:///home/galder/access/as-rel/trunk/client/jboss-system-jmx-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-system-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-srp-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-serialization.jar file:///home/galder/access/as-rel/trunk/client/jboss-security-spi.jar file:///home/galder/access/as-rel/trunk/client/jboss-remoting.jar file:///home/galder/access/as-rel/trunk/client/jboss-metadata.jar file:///home/galder/access/as-rel/trunk/client/jboss-messaging.jar file:///home/galder/access/as-rel/trunk/client/jboss-mdr.jar file:///home/galder/access/as-rel/trunk/client/jboss-main-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-logging-spi.jar file:///home/galder/access/as-rel/trunk/client/jboss-logging-log4j.jar file:///home/galder/access/as-rel/trunk/client/jboss-logging-jdk.jar file:///home/galder/access/as-rel/trunk/client/jboss-jsr77-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-javaee.jar file:///home/galder/access/as-rel/trunk/client/jboss-jaspi-api.jar file:///home/galder/access/as-rel/trunk/client/jboss-j2se.jar file:///home/galder/access/as-rel/trunk/client/jboss-integration.jar file:///home/galder/access/as-rel/trunk/client/jboss-iiop-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ha-legacy-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ha-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-security-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-proxy-clustered-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-proxy-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-ext-api.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-ext-api-impl.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-core-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-ejb3-common-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployment.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployers-vfs.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployers-vfs-spi.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployers-core.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployers-core-spi.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployers-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-deployers-client-spi.jar file:///home/galder/access/as-rel/trunk/client/jboss-common-core.jar file:///home/galder/access/as-rel/trunk/client/jboss-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-aspect-jdk50-client.jar file:///home/galder/access/as-rel/trunk/client/jboss-appclient.jar file:///home/galder/access/as-rel/trunk/client/jboss-aop-client.jar file:///home/galder/access/as-rel/trunk/client/jaxws-tools.jar file:///home/galder/access/as-rel/trunk/client/jaxws-rt.jar file:///home/galder/access/as-rel/trunk/client/jaxb-xjc.jar file:///home/galder/access/as-rel/trunk/client/jaxb-impl.jar file:///home/galder/access/as-rel/trunk/client/jaxb-api.jar file:///home/galder/access/as-rel/trunk/client/javassist.jar file:///home/galder/access/as-rel/trunk/client/jacorb.jar file:///home/galder/access/as-rel/trunk/client/hibernate-annotations.jar file:///home/galder/access/as-rel/trunk/client/getopt.jar file:///home/galder/access/as-rel/trunk/client/FastInfoset.jar file:///home/galder/access/as-rel/trunk/client/ejb3-persistence.jar file:///home/galder/access/as-rel/trunk/client/concurrent.jar file:///home/galder/access/as-rel/trunk/client/commons-logging.jar file:///home/galder/access/as-rel/trunk/client/avalon-framework.jar file:///home/galder/access/as-rel/trunk/client/antlr.jar file:///home/galder/access/as-rel/trunk/client/activation.jar > /max > >> I imagine there is something similar for javadocs??? >> >>> /max >>> >>> > Max Rydahl Andersen wrote: >>> >> On Mon, 10 Nov 2008 15:27:30 +0100, Paul Gier <pgier(a)redhat.com&gt; >>> wrote: >>> >> >>> >>> Can you clarify a bit what you are asking for? >>> >>> The maven standard for source jars is just to append "-sources" >>> to the >>> >>> name. So things like the dependency plugin and m2eclipse use that >>> >>> convention to find sources that are associated with a particular >>> jar. >>> >> I'm asking if we have that for *every* jar in AS so we could use >>> it >>> >> when >>> >> setting up a server in Eclipse ? >>> >> /max >>> >> >>> >>> Max Rydahl Andersen wrote: >>> >>>> Note, client api is one thing; the other is server side API and >>> being >>> >>>> able to figure out >>> >>>> which source jar goes with which runtime jar in JBoss AS. Having >>> pom >>> >>>> info for that would >>> >>>> be good...is that doable ? >>> >>>> /max >>> >>>> >>> >>>>> 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 >>> >>> >>> >

On Thu, 06 Nov 2008 17:28:04 +0100, David M. Lloyd <david.lloyd(a)redhat.com&gt; wrote: > Are there mechanisms which Eclipse *will* read? Does intellij read the manifest.mf and use it at compile time ?

> Do we have an Eclipse plugin for jboss-classloading.xml support yet? :-) Did you submit a request/patch for JBoss Tools detailing what you need/want yet ?

Yeah, IDEA can use a maven POM file as a project file (i.e. use the Maven model as a project model instead of having to manually create a project). It seems to work reasonably well, especially when you have a Maven project that also knows about the source files for libraries. This way, not only do you not have to worry about the dependencies but you also get to step in the code of libraries when debugging without having to set anything up. Quite a time saver when you have to deal with a modularized project.

> >> Are there mechanisms which Eclipse *will* read? > Does intellij read the manifest.mf and use it at compile time ? No, it doesn't seem to, unfortunately.

Supposedly it will read Maven POM info but I've not tried it myself.

>> Do we have an Eclipse plugin for jboss-classloading.xml support yet? >> :-) > Did you submit a request/patch for JBoss Tools detailing what you > need/want yet ? Nah, I don't want anything. IDEA rules!!!

:-) - DML _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

What does eclipse need then, bundle manifest headers? Ship a ant script/java class that lets the user make an uber jar from the manifest classpath. 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, >> >> _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development