Wow. thanks Tod. although lengthy, definitely reassures me that we are not alone in our troubles.
Perhaps our jar and test-jar is not working because the jar is a jar classifier b/c the project itself is a war. Eugene, can you point me to the bug in jira so i can see if it is the same scenario? When you say "modules", do you mean aggregation? or just your own internal dependencies? This is more a pure maven question, but I haven't been able to wrap my head around the purpose of aggregation in maven. You end up with all these subprojects, that I guess you could use as dependencies elsewhere, but then its not a module anymore. The biggest headache we're having is extending wars. But I seem to have worked around it now. The war plugin needs a bit of work to add things to the classpath etc. It does do a lot though, although xdoclet could be better integrated. Anyway, thanks again. -Ben ----- Original Message ----- From: Tod Harter <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, February 7, 2007 9:54:40 AM GMT-0500 US/Eastern Subject: Re: [m2eclipse-user] double dependency There are some issues apparently, BUT it does seem like for us having a depency on a jar and the corresponding test-jar works OK. There may be some situations where it doesn't work, I'm not sure, but I have a number of POMs that at least correctly resolve the dependencies. While these kinds of things seem to work well enough to let you do basic stuff in the IDE (IE you can compile and test) my experience is that complex multi-module building, like what you would do for a full-up build or complete integration testing are pretty problematic from within the IDE for a variety of reasons, most of which I haven't really delved deeply into. The best approach IMHO is to rely on command line mvn for that kind of thing and relegate using the plugin for everyday module level build and test. In our environment, which basically has dozens of modules in a variety of product/sub-product categories we rely entirely on a structured approach. Each developer can check out, build, and work with any particular set of modules. Everything gets checked out automatically by the build system periodically at the HEAD revision by the automated build system and a full build happens. Once a developer gets a branch of a module to a stable candidate point they can perform the equivalent build on their system using whatever mix of branch/trunk revisions they care to use. If they're satisfied the master build SHOULD work, things can be merged back to HEAD. Naturally the next master build MAY break, at which point they have a mess to clean up... Once a master build passes all the modules get deployed to the group-wide mvn repository, and everyone will see the new modules. We use shell/cron and some perl scripts to set up these builds, but you could try using Continuum for that. Personally I just find Continuum really hasn't gotten to the point where it can handle all the various setups required. You really have to do 4 or 5 different mvn invocations to put together a proper master build with stuff as complex as we have, and the only thing that can handle that is custom scripting. Overall things work pretty well, but there are still issues. For one there is no easy way to avoid a lot of redundancy in the master build. Between Cobertura and other reporting stuff and integration test etc most of our module level tests end up running at least 4 or 5 times in a build. The other pain is that there really isn't a competent plugin (or even Ant extensions) that can reliably handle setting up and testing J2EE stuff. Cargo can do some things OK, but frankly the chances of a sequence of builds and tests that involves setting up, starting, deploying, testing, undeploying, and shutting down JBoss several times (and some testing actually requires more than one JBoss on local and remote systems at the same time) is just about nil. Once you get to that point you pretty much have to do it all by hand. Sorry if that was ultra-lengthy and wandered far off the original topic ;) Ben Tatham wrote: > Has anyone had double dependencies work? I have the same > groupId/artifactId with different type/classifiers. It works from the > command line, but M2Eclipse only picks up one into the classpath... > > For example: > > <dependency> > <groupId>ca.nanometrics.apollo</groupId> > <artifactId>core</artifactId> > <version>1.0.1</version> > <classifier>jar</classifier> > </dependency> > > <dependency> > <groupId>ca.nanometrics.apollo</groupId> > <artifactId>core</artifactId> > <version>1.0.1</version> > <type>war</type> > <scope>runtime</scope> > </dependency> > > <dependency> > <groupId>ca.nanometrics.apollo</groupId> > <artifactId>core</artifactId> > <version>1.0.1</version> > <type>test-jar</type> > <scope>test</scope> > </dependency> > > In my classpath in Eclipse, all I get is core-1.0.1-jar.jar. (Note > that I don't expect the war in the classpath, but I do want > core-1.0.1-tests.jar). > -Ben > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
