maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Duell (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MENFORCER-62) requirePluginVesions: avoid checking commandline-invoked mojos
Date Wed, 14 Oct 2015 16:02:05 GMT

    [ 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)

Mime
View raw message