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