Brian Fox wrote:
1) we included some plugins that are commonly used but aren't in a
lifecycle such as the dependency and enforcer plugins.
I know, if those are declared in the POM they have to have/inherit a
version or Maven 3.0 will output a warning.
In other words, what we consider "commonly used" would no longer get
special treatment. A plugin is either used by a lifecycle mapping or not.
2) what are the impacts to the plugin when it's run in multiple
lifecycles, or if the user binds it to a phase of some other
lifecycle? Would this cause the version to vary in unpredictable ways?
Good questions, let's look closer at the edge cases:
A reminder first: For a given project, Maven 3 will use exactly one
version of a plugin.
For a single lifecycle mapping that defines the same plugin multiple
times with different versions, the first version would win.
For multiple lifecycles, we would need to define some canonical order of
the lifecycles (e.g. alphabetical by id, "clean", "default", "site") to
reliably solve version conflicts from potentially different lifecycle
mappings for the different lifecycles. Right now, the lifecycle executor
inspects the lifecycles in injected/arbitrary order.
The POM would be dominant over the lifecycle mapping. So any <plugin>
declarations the users puts into it will override the version given in
the lifecycle mapping, regardless from what lifecycle.
Another interesting case is the (deprecated) release profile. Given that
neither the Javadoc nor the Source Plugin are part of the lifecycle
mapping, they would no longer have default versions and Maven 3 will
output warnings unless a child POM locks them down.
3) what is the impact to direct cli invocation now?
The resolution process for a missing plugin version is
1. project/build/plugins
2. project/build/pluginManagement/plugins
3. RELEASE/LATEST from repository
So, if the plugin in question is declared in the POM (or any parent),
the version from the POM will be used. Otherwise it's back to the auto mode.
For instance, if someone invokes "mvn compile:compile" on a JAR project,
the same version will be used as for "mvn compile", because the
lifecycle mappings will be reflected in the effective POM and as such
provide the version for the maven-compiler-plugin.
If someone invokes "mvn install:install-file" on a POM-less directory,
the plugin version would be resolved from the repo metadata instead of
the super POM defaults.
To sum up, there will be cases where we loose default versions compared
to 2.x but IMHO those are acceptable and weigh less than the problem
with versioned lifecycle mappings we're trying to solve. As a side note,
I like the idea to eventually see the super POM being free of any plugins.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
