Hi,
I'm an avid Maven 1 user, but there are some things that cause me
consistent headaches. I'm wondering if they are being addressed in
Maven 2, and if not, whether a discussion can be opened about them.
This is a general list off the top of my head, I can provide more
description and details as requested.
1. Plugins (jar/war/etc) which insist on running tests internally
before they will do anything, and don't provide an easy way to
override this:
- This causes problems when I want to build artifacts (jars/wars)
for integration testing, or during the build process (for example,
generating test webservice stubs by building a war, deploying in
jetty, and running wsdl2java against it). If I make pregoals to
test:compile to ensure the artifacts are built, then I get multiple
test runs, or even worse, endless loops. I've even gotten one project
so convoluted that it doesn't run the tests at all after a clean, but
will run them if you have not just done a clean (haven't had time to
figure that out yet).
- I have gotten around this by having 'disabletests' and enabletests'
goals, which manually set the maven.test.skip property (preserving
whatever the previous value is). Needless to say, this is painful and
error prone.
2. Forced and inflexible segregation of app and test classes:
- I know this has been the subject of flaming religious wars on the
maven user list, but I'm convinced that there are places where the
"just do it because that's the way it is" line doesn't cut it. Here
are some real cases where I wish I could flexibly control where the
compiled app/test classes are created and accessed:
- First, in the case of AOP where you have circular dependencies
between app and test classes. YES, there are legitimate reasons for
this (see note A below). To get around this, I currently have to
compile EVERYTHING (app and test classes/aspects) to target/classes
(${maven.build.dest}), and then have a custom goal which identifies
the test classes (which correspond to a test source file), and move
them to target/testclasses (${maven.build.dest}). In this case, it
would be simpler to just point maven.build.dest and maven.test.dest to
the same location for a test run, then clean and recompile just the
app classes to maven.build.dest for a deployement (to avoid including
test classes in the deployable).
- Second, in the case of code coverage tools or any other plugin which
instruments/weaves/modifies app classes in a way which you do not want
to deploy (I'm working on the EMMA plugin). For example, if you want
to instrument the classes to generate code coverage during tests, you
have to do a full recompile before deployment to avoid shipping
instrumented classes. The clover plugin gets around this by hacking
on the maven.build.dest value, and forcing the user to call clover:on
and clover:off goals (plugin.jelly, rev 1.28). However, this just
seems kind of ugly, and in need of a cleaner more standardized
approach.
- I realize that these problems may be unsurmountable while still
maintaining backward compatibility with other plugins, but I'm just
wondering if any thought has been put into these types of issues.
3. Single-artifact per-project requirement
- Will maven2 still enforce the single-artifact-per-project rule? One
place where this causes me problems is on web-service projects, where
I would like to generate a WAR, and also generate a jar or other
artifact containing web service stubs. Multiproject is not really
applicable in this case, because the stubs are used both internally
(for integration testing of the webservice webapp itself) and as a
deployable (published in a jar for other projects which will be
clients of the webservice).
Thanks in advance. I'm looking forward to Maven2, keep up the good work.
Chad Woolley
NOTE A: Reasons why it is legitimate to have circular dependencies
between app and test classes:
1. There are test aspects that effect the app classes, because they
are overriding behavior to do mocking. Yes, I know jmock/easymock are
preferred, but they don't work for all cases, sometimes AOP is better.
2. There are non-production "stub" classes in the test tree, which
are used to test production aspects in the app tree. This is to unit
test the aspects, and verify that they have the intended effect on a
class, without using an actual production class, which would be more
complicated and mix the concerns of testing the class and testing the
aspect.
