requirePluginVesions: avoid checking commandline-invoked mojos
--------------------------------------------------------------
Key: MENFORCER-62
URL: http://jira.codehaus.org/browse/MENFORCER-62
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-alpha-4
Environment: Maven 2.0.8, 2.0.9
Linux,Windows
Reporter: Petr Kozelka
Locking plugin versions affects also mojos invoked from commandline, which is
typically undesired.
Besides that, such mojos cannot be even invoked with fully qualified name.
I am using following configuration in our corporate pom, to enforce that all
plugin versions are explicitly declared so that builds are reproducible:
{noformat}
...
<message>ERROR: Please always define plugin
versions.</message>
<banLatest>true</banLatest>
<banRelease>true</banRelease>
<banSnapshots>false</banSnapshots>
<banTimestamps>false</banTimestamps>
<phases>clean,deploy,install</phases>
...
{noformat}
With this config, I cannot use commandline mojos that are not mentioned with
exact version.
One such case is {{mvn idea:idea}} which ends with enforcer failure.
*Even worse*: in this case I have {color:red}no chance to invoke{color} that
mojo even with full qualifier - it fails as if I didn't specify version (maybe
this part is a bug in different component):
{noformat}
mvn org.apache.maven.plugins:maven-idea-plugin:2.2:idea
{noformat}
I can theoretically add something like this to the corporate pom, and it really
helps:
{noformat}
...
<unCheckedPlugins>
<unCheckedPlugin>org.apache.maven.plugins:maven-idea-plugin</unCheckedPlugin>
</unCheckedPlugins>
...
{noformat}
However, this approach is generally unusable, as it requires re-releasing of
all modules descending from that pom - which is never desired and rarely
possible.
h3. A semi-solution idea:
This might be difficult to fix - but if the list of unchecked plugins was
somehow externalizable, it would solve my urgent need.
For instance, add option {{unCheckedPluginList}} containing comma separated
items - then I can reference a property defined in {{settings.xml}} from there.
That would work for me, because settings are not subject to releasing:
{noformat}
...
<unCheckedPluginList>${my.unchecked.plugins}</unCheckedPluginList>
...
{noformat}
--
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
