Except Maven has no idea how to reach a state when “Module B must exist”, because plugins don't tell Maven that they'll create that specific artifact. For a module with <package>jar</package> and not too much customization, it's easy to infer that moduleb:jar would exist after running up to the package phase of the moduleb module; similarly for a WAR or EAR. But how about test-jar and java-sources? (not all of them are packaged using the maven-jar-plugin or maven-source-plugin) how about zip files and other assemblies? Maven would have to use heuristics based on specific plugins (maven-jar-plugin's test-jar packages a test-jar, maven-source-plugin's jar-no-fork packages a java-source); this is bad for modularity, and too error-prone.
On Thu, Mar 27, 2014 at 1:49 PM, mkarg <[email protected]> wrote: > I understand the issues, but I do not see why we should all just sit back > and > say "Maven is broken by design, so all is good, just keep it as it is.". I > do not see that it is unfixable wrt the original question, as only thing I > asked for is that Maven accepts that if Module A needs Module B then it is > obvious that Module B must exist. In the end it is just a need for partial > serialization. I mean, I can even fix it by hand (merging two poms in one > and all works fine, as the executions run top to bottom), so it MUST be > possible to do just this partial fix in Maven core. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/multi-module-phases-sequence-tp5789365p5789696.html > Sent from the Maven - Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Thomas Broyer /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
