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]
