Vincent Massol wrote: >>In the case of building "core", it's type could be that of a specific >>aggregated JAR, so install would trigger the install for that. This >>should be how EARs work too, though I'm yet to put it into practice. >> >> > >Just to be sure I understand: Are you saying you are planning to support >creating an aggregated jar when calling "m2 install"? Or is it just an idea >that it could be supported but you're still unsure about the UC so you're >holding off for now? :-) > > The latter. I think it's more valid for an EAR, and to build a distribution of a multiproject - though I'm still unsure what is the best way to go with them. In the case of an EAR I think it makes sense rather than to create a subproject with dependencies. For a distribution, while I think it makes sense it worries me that it would bahve differently to when someone makes a distribution for a single product.
> > > >>I'm still skeptical your use case below is a good idea. Every time you >>add a new different way of distributing your code, you add some >>confusion for your users. >> >>I presume there is a good reason you separated util, module and >>container - so why pull them back in together again? >> >> > >I've separated them for 2 reasons: >1/ to physically ensure that I have no dependencies in the direction util -> >module, util -> container and module -> container. > > sounds reasonable >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? >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'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. Cheers, Brett --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
