Re: [jboss-dev] jbossall-client.jar now references external libs

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