Yeah, upon thinking about this a little more, I think it could be a really bad idea to expose the "live" BuildPlan to plugins, at least without making it a read-only view. Instead, I'd much rather provide a second extension point for Maven that's well-defined and well-documented like the basic Mojo interface is (all cheap shots about parameter and mojo annotations aside, of course). This new extension point would simply allow the component to post-process the build plan before it's handed back to the rest of Maven for execution...and if we provided a view of the build plan to plugins and such, this post-processed version is what they would see. This would do a better job of isolating the build-plan modifications to a very narrowly defined part of the build pre-lifecycle (if you like), and not open it up for questions of timing such as, "My plugin modifies the build plan to inject a new mojo into generate-sources, but the plugin itself doesn't run until the package phase...can we make that work?"
-john On Feb 1, 2008 4:22 PM, Joerg Hohwiller <[EMAIL PROTECTED]> wrote: > -----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] > > -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
