You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Petr Kozelka (JIRA)" <ji...@codehaus.org> on 2009/02/05 15:06:19 UTC
[jira] Created: (MENFORCER-62) requirePluginVesions: avoid checking
commandline-invoked mojos
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
[jira] Closed: (MENFORCER-62) requirePluginVesions: avoid checking
commandline-invoked mojos
Posted by "Brian Fox (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MENFORCER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brian Fox closed MENFORCER-62.
------------------------------
Assignee: Brian Fox
Resolution: Fixed
Fix Version/s: 1.0-beta-1
converted to a comma separated list
> 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
> Assignee: Brian Fox
> Fix For: 1.0-beta-1
>
>
> 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