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
