> -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: lundi 25 avril 2005 02:33 > To: Maven Developers List > Subject: Re: [m2] Jar aggregation use case (was RE: cvs commit: maven- > components/maven-plugins/maven-assembly- > plugin/src/main/resources/assemblies jar-with-dependencies.xml)
[snip] > >2/ I would like to possibly distribute the modules jar separately in the > >future but this is still unsure and we're not ready yet to do this. > > > > > > > But define "distribute". For Maven2 users, surely they only need to > depend on one of these and the others get pulled in by transitive > dependencies? Is anyone else using the aggregated JAR, or are they > downloading a tarball with all these JARs included? By distribute I mean to make available a single JAR file (instead of 3 jar files). > >I agree that it makes sense only at distribution time. However, I'm a bit > >hesitant to distribute a JAR that hasn't been tested... The individual > JARs > >would have been tested. I would be more confident if the samples/* > projects > >were exercising the aggregated JAR to be sure it's working fine. I think > >there might always be some classloaders issue that would make the > individual > >jars work but that would make the aggregated one fail. > > > > > Good point, but is also one of the reasons that I said adding different > ways to distribute your code may not always be a good idea. So you'll > want to be sure that there is a definite reason for this JAR to exist in > the first place. I agree that having different ways to distribute one's code is bad. I only want 1 way for Cargo: one JAR which is the aggregation of the 3 individual JARs. User don't see the individual jars (they are private artifacts). Actually and coincidentally Milos sent an email yesterday on the Cargo mailing list reporting that he had found the error why his cargo integration in mevenide wasn't working. That's because he was using the individual Cargo jars (which he got from building cargo from the sources and not from the distribution) instead of the unique cargo jar and there was a classloader issue... ;-) > >I'm quite open on all this and it's probably a minor thing. I still think > we > >should allow an aggregated JAR to be produced when running "m2 install" > on a > >special pom packaging (like <packaging>aggregated-jar</packaging>). > > > > > I'd still like to ponder over this some more. If we do it for EARs, it > is probably reasonable for JARs too. This is on the list for alpha-2... > I think the lifecycle may consume too much time though, so let's slot it > in for first thing in alpha-3. > > They are really the main two design issues I think are still outstanding. Fine. I'm not in dire need of this. I'm just using Cargo to test m2, see what can be done with it right now and to what extent and possibly help fine-tune m2. To recap on Cargo's build, I'm currently blocked by 3 things: - no aggregated jar - no checkstyle plugin so I can't make the build fail upon checkstyle errors - no EAR plugin so I can't build the sample testdata projects which prevents me to move the sample projects' builds to m2 Then there are second level features that I'm missing compared to the existing build: - no clover plugin - no site but that's secondary because I use confluence for Cargo's web site Also, I haven't tried deploying to codehaus yet. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
