Hi Vincent, IMHO points 1 and 2 seem to break Maven "philosophy". The Cactus distribution should comprise more than one jar, and that shouldn't be a problem. I thinked about using files from a dependency jar in order to share information between different projects, for example Spring database configuration parameters common to many webapps, it's defined in a common project and extracted to target/webapp/WEB-INF before building a war archive. This is similar to what you say, you can extract classes from a dependency jar to build/classes before calling jar goal.
About point 3 I'm currently using multiproject:site but I suppose this doesn't suit your needs. Carlos Sanchez A Coru�a, Spain Oness Project http://oness.sourceforge.net > -----Mensaje original----- > De: Vincent Massol [mailto:[EMAIL PROTECTED] > Enviado el: domingo, 23 de mayo de 2004 22:13 > Para: 'Maven Developers List' > Asunto: [Strategy] How to manage several subprojects as one project? > > Hi guys, > > I'm still trying to slowly convert the Cactus build (which > uses Ant) into a Maven build. Here's a use case I have. > Currently I have the > following: > > framework/ > |_ src > |_ share-12-13-14 > |_ share-13-14 > |_ j2ee-12 > |_ j2ee-13 > |_ j2ee-14 > |_ build.xml > |_ [...] > > Where 12, 13, 14 represents the J2EE APIs (1.2, 1.3 and 1.4 > respectively). The share directories contain common classes > for the different API versions. Of course the build for the > different APIs have different dependencies. > > To transform this into a Maven 1.x build, it seems that what > makes most sense is to have the following: > > framework/ > |_ share-12-13-14 > |_ src > |_ share-13-14 > |_ src > |_ j2ee-12 > |_ src > |_ j2ee-13 > |_ src > |_ j2ee-14 > |- src > > (i.e. a project per src directory). > > However, there are several issues: > 1- I don't want to publicly expose the share-12-13-14 jar > artifact for example. Thus it would be best to have some > interproject "channel" that do not go into the local Maven repo. > 2- I still to only deliver 3 jars (one for each API), thus I > need to regroup the different jars. For example for J2EE API > 1.3, I need to regroup the share-12-13-14 + share-13-14 + > j2ee-13 jars. I don't think that uberjar does exactly this. > Of course it should be possible to develop a plugin for this > if there is no other solution. It's a bit of a pain to have > to jar the output from subprojects to then have to unjar jar > to again rejar everything a main framework jar. It would be > nice to be able to exchange classes artifact between the > different subprojects. > 3- More generally, I'd like to consider the framework project > as one virtual project, i.e. have only a single site, single > javadoc, etc. > > In light of this, it seems to me that the only reason to have > different subprojects is to have the ability to define > different dependencies for the different J2EE APIs. Thus > maybe there is another solution using dynamic dependencies > (not sure how that would work though). > > Any take on this use case for Maven 1.x? > > Is that a known use case for m2? > > Thanks > -Vincent > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
