-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there, | Right...I guess it'd help to include the URL: | | http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning | | Thanks!
I generally agree with what you are saying. You are pointing out common problems very well. The solutions sound promising but here some further comments... | some plugins may need to be omitted in rare cases, | but ideally would be configured in the parent POM | for the 95% of child modules that do need it. | Here, it would be simpler to allow the child POM | to direct Maven to omit that plugin execution for its own build. To underline this one: http://jira.codehaus.org/browse/MNG-3321 http://jira.codehaus.org/browse/MECLIPSE-271 http://jira.codehaus.org/browse/MSELENIUM-21 http://jira.codehaus.org/browse/MCHECKSTYLE-43 http://jira.codehaus.org/browse/MHIBERNATE-50 http://jira.codehaus.org/browse/CARGO-481 | As mentioned above, the concrete LifecycleBindings/MojoBinding | model classes - along with the BuildPlan derivative | used to inject direct invocations and forked | executions - provide an easy way to inspect and | manipulate the list of mojos that will execute | during a particular Maven build. However, this | is worth highlighting separately: where 2.0.x | provided an immutable and obscure LifecycleMapping | class collected by lifecycle-name into a | java.util.Map instance, contained as a private | member of the DefaultLifecycleExecutor, Maven 2.1 | will present a concrete, strict syntax and class | model that can be built, rendered, inspected, | and manipulated via documented APIs. I am not quite sure if I get it right. But one the one hand you are saying, that the BuildPlan should be calculated first and potentially viewed to the user (e.g. via -X) to make build transparent and deterministic. On the other hand you are saying that each plugin can access the BuildPlan via an API and make modifications. How do these two points go together? The modification of the BuildPlan might be a very cool generic feature but please consider to add an ultra fat warning to the javadocs NOT to do this if there are better ways. This should not open the gate for ugly hacks. Whenever there are ways to do something, they will be used by someone. You know why Java was so successful? Because it is so restrictive and easy (at least before java5). Beside I would be pleased if you could revisit these two issues in this context: http://jira.codehaus.org/browse/MNG-3377 http://jira.codehaus.org/browse/MNG-3322 Thanks a lot ~ Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHo42ZmPuec2Dcv/8RAs7OAKCQXhGKoMah+dKpBxbELs+VOe3mPQCgjQIO u10CCbiULT16/Q3z1Qdhvfs= =l1FM -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
