Hi Rafal, Thanks for your good feedback. I have 2 comments:
1/ Performing a jar then an unjar and again a jar is time consuming. There is really no need to do this. It is forced on us by Maven which is not so good. It's the same situation if you're doing code generation. ATM you have to pass the source jar to a second project that will unjar them to generate code from the source. Maybe a solution would be to have a new artifact type of "classes" which would point to the top level of package directories. That was there is no need to jar and unjar. Or more generically an artifact type of "directory" structure where you can put anything expanded in there (source code, class files, etc)? 2/ These share-12-13-14 and share-13-14 subprojects have no functional meaning and I'd like to have a single javadoc report, a single site, a single checkstyle errors, etc. I think this point 2 is my main problem. It's fine to have several subprojects when they have a functional meaning but I don't feel this is the case. This problem is all the more evident in that Cactus already has an existing build which does this and it's hard to justify to users that we have something "less" good because of a technical problem. If we don't have a single site, looking at reports is harder because you have to navigate to different location to get a full vision (which is BTW the reason for the dashboard plugin I have started). Any other ideas? Thanks for your help -Vincent > -----Original Message----- > From: Rafal Krzewski [mailto:[EMAIL PROTECTED] > Sent: 26 May 2004 00:08 > To: Maven Developers List > Subject: Re: [Strategy] How to manage several subprojects as one project? > > Jason van Zyl wrote: > > 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 > > I think it's a bad practice. I always put this setting in my > build.properties: > maven.buil.dir=/home/rafal/maven-targets/${pom.groupId}/${pom.artifactId } > This is to avoid swamping my eclipse workspace with thousands of > generated files. Boosts search performance a great deal, eliminating > false positives at the same time. This is probably useful with other > IDEs too! > So, I would recommend pulling the artifact from the local repo in such > situations. > > > 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? > > Jason is right. Everthing that shows up in your local repo during build > process through *:install[-snapshot] can be considered your project's > private data. Only artifacts that you *:deploy[-snapshot] are the public > stuff. Excuse me if I missed something important in the earlier > discussion, but I think you could build your private partial jars in > separate projects, and then combine them together in other agregator > projects. You could specify explicit dependencies among all of these, so > that reactor built them in the correct order. The aggregator projects > would have to use a bit of custom jelly scripting to pull the required > jars from the local repo, unzip them and zip the whole thing together > again. You would probably need a custom goal for doing the deployment, > you don't want to just run multiproject:deploy, because it would publish > your internal jars. You could override jar:deploy and > jar:deploy-install goals in the partial jar projects to fail in order to > prevent deploying them accidentally. > I think this strategy if pretty straightforward, follows Maven's single > project - single artifact philosophy, and can be easily layed out in a > flat (no project nesting) Eclipse friendly way. > > cactus-parent (parent POM for all projects) > cactus-build (multiproject driver) > cactus-partial-12-13-14 > cactus-partial-13-14 (dep. -12-13-14) > cactus-partial-12 (dep. -12-13-14) > cactus-partial-13 (dep. -12-13-14 -13-14) > cactus-partial-14 (dep. -12-13-14 -13-14) > cactus-jdk12 (dep. -12-13-14 -12) > cactus-jdk13 (dep. -12-13-14 -13-14 -13) > cactus-jdk14 (dep. -12-13-14 -13-14 -14) > > hope this helps. > > R. > > --------------------------------------------------------------------- > 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]
