Jerome, Thank you for your answers. However my goal is to use Maven and to discuss a possible strategy within Maven to support this use case. The Cactus project already has a build and it works fine. I'm trying to figure out the best possible strategy with Maven.
So far you're the only one to have provided your view. I was hoping to get other Maven developer's feedback too. Thanks -Vincent > -----Original Message----- > From: Jerome Lacoste [mailto:[EMAIL PROTECTED] > Sent: 25 May 2004 14:05 > To: Maven Developers List > Subject: RE: [Strategy] How to manage several subprojects as one project? > > On Mon, 2004-05-24 at 08:09, Vincent Massol wrote: > > Hi Jerome, > > > > > -----Original Message----- > > > From: Jerome Lacoste [mailto:[EMAIL PROTECTED] > > > Sent: 24 May 2004 06:48 > > > To: Maven Developers List > > > Subject: Re: [Strategy] How to manage several subprojects as one > > project? > > > > > > On Sun, 2004-05-23 at 16:13, Vincent Massol wrote: > > > > 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 > > > > > > I am not a maven expert at all, but with regards to not exposing your > > > shared jars, what about the following: > > > > > > - your build is a 2 stage process where you first build the required > > > dependencies and place them in a local repository > > > - the second phase uses your built jar files to finish the work and > > > publish > > > > > > e.g. > > > > > > target/tmp-repos/share-12-13-14/jars > > > target/tmp-repos/share-13-14/jars > > > etc... > > > > > > project.properties=... > > > manve.remote.repos=[ibiblio...],./target/tmp-repos/ > > > > Is that something you've done in practice? > > No.... > > > How do you deploy your jars > > to the local repository (will jar:install work with several > > repositories?) > > copying manually ? > > > How do you manage (in term of time-consumption) the fact > > that Maven will try looking first on ibiblio, display some error message > > and then only try the second repos? > > this I can answer because I don't use ibiblio on my personnal projects. > I always have ibiblio first and local repos after and it's not slow (on > Linux) > > > How do you solve the other issues I have listed above, namely points 2 > > and 3? > > don't know! > > > > You may need to make a split into your dependencies & your project, > > using > > > sub-projects. But I think this should work with the. > > > > > > Would that work? > > > I think it solves 1. > > > > In theory yes. In practice I don't think so :-) > > > > I still need to get a solution for the other points though. > > Maybe that doesn't cut it... > > Are you sure you want to use your own sub projects? > What about handling the problem in a simpler way. Keep something similar > to the original layout and try to make the compilation, the jars yourself? > > It's not cute but if it works.... > > Jerome > > > --------------------------------------------------------------------- > 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]
