----- Original Message ----- From: "Vincent Massol" <[EMAIL PROTECTED]> To: "'Maven Developers List'" <[EMAIL PROTECTED]> Sent: Wednesday, May 26, 2004 8:53 AM Subject: RE: [Strategy] How to manage several subprojects as one project?
> 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)? You can already do it with resources tag in pom. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
