> -----Original Message----- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: 25 May 2004 19:38 > To: Maven Developers List > Subject: RE: [Strategy] How to manage several subprojects as one project? > > On Tue, 2004-05-25 at 12:05, Vincent Massol wrote: > > Hi Carlos, > > > I still believe we're missing a "local/private" repository kind of stuff > > to share non-public data between projects. Or something equivalent. > > I honestly don't understand this requirement. What is really the > difference between referencing the generated artifact from the local > repository or the target directory of the build in question. Which you > can do with a JAR override: > > maven.jar.foo = ${basedir}../other-project/target/whatever.jar > > Or with the unified source directory in m2 this will also be easy. > > But what do you really see as the problem with deploying JARs to the > local repo for use amongst your projects?
There is really no real functional requirement for building a jar for share-12-13-14 and share-13-14 as these jars do not have any meaning at all. Creating a jar of them and then unjarring them to rejar them all together seems like a waste of time. It doesn't seem a sound practice. Jason, I don�t know how to solve my general use case today with Maven. I need to transform the following Ant build: > > > > 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. In the end depending on which J2EE API the framework/ project is built against, it should deliver a cactus-j2ee-<api>.jar. share-12-13-14 and share-13-14 have no functional meaning. They just contain classes that are common. Ideally I'd also like to have a single site for the framework/ project, a single clover report, a single javadoc report, etc. How would you transform that into a Maven build? Thanks! -Vincent PS: Where can I find more information on the "unified source directory"? It looks interesting. > > > 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] > > -- > jvz. > > Jason van Zyl > [EMAIL PROTECTED] > http://maven.apache.org > > happiness is like a butterfly: the more you chase it, the more it will > elude you, but if you turn your attention to other things, it will come > and sit softly on your shoulder ... > > -- Thoreau > > > --------------------------------------------------------------------- > 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]
