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? How do you deploy your jars to the local repository (will jar:install work with several repositories?) 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? How do you solve the other issues I have listed above, namely points 2 and 3? > > 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. > > Can you work from there to satisfy the other requirements? How? :-) Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
