[
http://jira.codehaus.org/browse/MNG-4058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=167342#action_167342
]
Markus KARG commented on MNG-4058:
----------------------------------
(Unfortunately it seems that I have no enough access rights to modify a cloned
issue -- actually this shall be a feature request)
Maven embraces the "Covenience over Configuration" pattern to reduce the amount
of configuration efforts one must invest to get things done.
Following Wilfredo Pareto's "80-20-Rule" (Law of Pareto), 80% of a goal's use
cases should work as intended by only investing 20% of all possible
configuration efforts. Or in simpler words: A goal should work as one expects
it to work without too much configuration.
There are a lot of goals that virtually every plugin user (not just 80% of
them) will use in exactly the same way, i. e. everybody will always bind the
same goals to the same phases in all projects. There just is no dependency at
all of the particular goal to the user, the project or anything else. The
plugin will nearly always getting applied in exactly the same way. Or in other
words: To fulfil the Law of Pareto, these kind of plugins should work without
explicit execution binding.
Maven already comes with lots of these automatically "default-executed" goals,
like compile:compile, which are bound in such a default way already (but using
the SuperPOM or a different technology to imply the default execution binding).
Custom plugins (and lots of third party plugins) are not covered by the
SuperPOM solution automatically, nor makes it sense to provide a custom
lifecycle or packaging just to get them executed without adding an execution to
the project's POM.
Unfortunately all of the possibilites to get a "default-executed" goal (i. e. a
goal that executes at a phase without adding an execution to the project's POM)
have severe negative side effects: Either the user must configure them
somewhere else (this is what we want to prevent actually, so it would be a
Pyrrhic victory), or the original packaging or lifecycle is modified (what the
user might not want).
So despite the fact of having a lot of possibilities to get a goal bound to a
phase, in reality there are two solutions missing (and in fact, it is the most
simple one that is missing):
(1) Let the plugin USER decide to execute ALL goals of a plugin at their
DEFAULT phase:
<plugin>
...
<executions><auto/></executions>
...
</plugin>
This will result in the same behaviour as writing a lenghty list of all the
goals to execute.
(2) Let the plugin PROGRAMMER decide about default executions:
/*
* @goal mygoal
* @phase generate-resources
* @auto
*/
This hypthetical @auto annotation will make maven execute this goal at the
specified phase UNLESS the USER of the plugin provided a different <execution>.
As a result, the majority of the users will not write any <executions> blog for
this plugin, making it pretty easy to use this plugin.
An alternative to these two ideas would be to make it even simpler: If we
wouldn't have the obvious need to keep backwards compatibility, then Maven
could just execute EACH goal marked with @phase ALWAYS, if there is no
<executions> provided, and fall back to the current strategy IF <executions is
provided. But this would break current projects.
> Support for Default Executions
> ------------------------------
>
> Key: MNG-4058
> URL: http://jira.codehaus.org/browse/MNG-4058
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
> Affects Versions: 2.0.10
> Environment: Windows XP Pro SP2
> JDK 1.6.0_10
> Reporter: Markus KARG
> Assignee: Benjamin Bentmann
> Priority: Critical
>
> The default phase binding is not working: My mojo contains @phase
> generate-resources, what results in a phase entry in the plugin.xml. But it
> is not getting execute at mvn compile (yes, there is no typo, I double
> checked. If I am adding an explicit phase binding (execution) to the pom, it
> IS getting execute. So the default seems to do just nothing.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
