[
https://issues.apache.org/jira/browse/MENFORCER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14957124#comment-14957124
]
Eric Duell edited comment on MENFORCER-62 at 10/14/15 4:01 PM:
---------------------------------------------------------------
... it's a comment in direct response to the solution. Both parameters are
still available. Just "the old" one was marked as deprecated. And I am
questioning if we can't remove the comment. But it's ok. I will create a new
issue (MENFORCER-242).
was (Author: eric.duell):
... it's a comment in direct response to the solution. Both parameters are
still available. Just "the old" one was marked as deprecated. And I am
questioning if we can't remove the comment. But it's ok. I will create a new
issue.
> requirePluginVesions: avoid checking commandline-invoked mojos
> --------------------------------------------------------------
>
> Key: MENFORCER-62
> URL: https://issues.apache.org/jira/browse/MENFORCER-62
> Project: Maven 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 was sent by Atlassian JIRA
(v6.3.4#6332)
