On 10/02/2010 07:27 AM, Brett Porter wrote:
mvn -am -pl main run
would automatically invoke just 'install' (or 'package') on the calculated
dependencies.
I don't agree that "install" on one and package on the dependencies would make
sense - this would put something in the repository that potentially doesn't
have its dependencies there, making it unusable by other projects.
You would rather install the dependencies, and run the selected project without its install phase, so the local repository would not be inconsistent. Or if the run goal
could work with reactor artifacts, just compile or package on the dependencies would suffice, i.e. without anything getting installed in local.
Let me provide a simpler example using only standard jar packaging and its default plugins. If I have a tree of modules using snapshot dependencies internally, and wish
to run unit tests on one of them while ensuring that the test classpath includes up-to-date class files from its snapshot dependencies, what should I run?
a. 'cd root/submodule; mvn test' will run tests for just submodule, but relies on JARs in the local repository for all the snapshot dependencies, which is no good; these
JARs might be missing, or old.
b. 'cd root; mvn test' will run the tests for submodule correctly, but also
tests in every other module.
c. 'cd root; mvn test -Dtest=sub/module/pkg/**' might run the right set of tests if you happen to have things in a particular package structure, but this is not general.
Anyway Surefire will fail the build on upstream modules because it found no tests to execute.
d. 'cd root; mvn install -DskipTests -am -pl submodule; cd submodule; mvn test' will run just tests for submodule and with correct snapshot dependencies, but will be much
slower as it builds JARs (and use of -DskipTests may be objectionable).
e. 'cd root; mvn test-compile -am -pl submodule; cd submodule; mvn test' will not work since the second Maven command is given no reactor, so it will not look up
dependencies in target/classes but in the local repository.
There seems to be no decent solution using current --also-make. The solutions
using the styles I proposed previously would look like:
1. mvn -am -pl submodule test-compile -then -pl submodule test
2. mvn --also-make-goals -pl submodule test-compile test
3. mvn --also-make-smart -pl submodule test [where test known to presuppose test-compile in dependents; compile would suffice if there were no deps on secondary test
artifacts]
(An IDE user might ask the IDE to just run JUnit on submodule/src/test/java/**/*.java bypassing Maven and Surefire and using some IDE-specific compilation of dependencies
from sources, if the IDE has been configured to run tests exactly the same way as the POM specifies Surefire should run them, but it would be best if command-line Maven
could do this to begin with.)
Does the issue make sense now, and is it worth filing a JIRA ticket for this?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
