On Thu, Mar 27, 2014 at 9:32 AM, mkarg <[email protected]> wrote: > This is weird. I mean, the POM contains all the information Maven needes to > understand that e. g. a MVN test on the dependent module implies an (at > least) MVN package on the dependency side. Otherwise the relationship > provided in this multi-module project could not get fulfilled. So why is > MVN > not simply acting in a logical way and package the dependency even when the > invocation just enforced a MVN test?
Legacy I believe. > That would do not harm and it would > make everything work as one expects. > That's not entirely true. It is true that creating moduleA:jar is generally done in the package phase, but that's not enforced, and there are all those secondary artifacts that can be packaged any time you want (e.g. at the verify phase). If moduleB depends on moduleA:test-jar or module:java-sources, nothing guarantees that they'd be packaged at the "package" phase of moduleA. There's also the open issue that if you do a "mvn compile" (or "mvn process-classes"), should Maven run the tests of moduleA (as part of calling its "package" phase, as you're asking) before compiling moduleB? And then there are also the custom lifecycles (but Maven already do a rather bad job here as it tries to call the same phase in all projects in the reactor) The problem is that plugins do not tell Maven about their inputs and outputs, so Maven cannot reason in terms of "what should I do before I can do what I'm asked to do". But even with that, it would be great, as a “workaround”, to be able to tell Maven, on the command line “run the package phase on all those modules, and the test phase on those” or even better “run the test phase on these modules and the package phase on all the modules they depend on” (enhanced “-am”). See http://blog.ltgt.net/maven-is-broken-by-design for other issues with how reactor (multi-module) builds are “broken by design”. -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
