Sorry, I am lost in a middle of this. What you've been trying to say? :-)
regards,
Eugene
Tod Harter wrote:
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
