Hi Carlos, The requirement to have a single Cactus framework jar is a *MUST* have (like a business requirement). It doesn't make sense to deliver 3 jars: cactus-share-12-13-14.jar, cactus-share-13-14, cactus-j2ee-<api version>.jar. These jars have no functional meaning at all. That wouldn't do for users.
I still believe we're missing a "local/private" repository kind of stuff to share non-public data between projects. Or something equivalent. Thanks -Vincent > -----Original Message----- > From: Carlos Sanchez [mailto:[EMAIL PROTECTED] > Sent: 25 May 2004 17:35 > To: 'Maven Developers List' > Cc: 'Vincent Massol' > Subject: RE: [Strategy] How to manage several subprojects as one project? > > 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]
