[
https://issues.apache.org/jira/browse/MENFORCER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14956445#comment-14956445
]
Karl Heinz Marbaise commented on MENFORCER-62:
----------------------------------------------
Please don't use jira a communication system. Please do such questions on the
user/dev list with reference to this issue...or better in this create a new
jira with reference to this issue with a suggestion to what you like to have as
a feature...
> 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)
