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/ 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. Can you work from there to satisfy the other requirements? Jerome --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
