Maven Enforcer Plugin
  1. Maven Enforcer Plugin
  2. MENFORCER-62

requirePluginVesions: avoid checking commandline-invoked mojos

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0-alpha-4
    • Fix Version/s: 1.0-beta-1
    • Component/s: Standard Rules
    • Labels:
      None
    • Environment:
      Maven 2.0.8, 2.0.9
      Linux,Windows
    • Number of attachments :
      0

      Description

      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:

      ...
                        <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>
      ...
      

      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 no chance to invoke that mojo even with full qualifier - it fails as if I didn't specify version (maybe this part is a bug in different component):

      mvn org.apache.maven.plugins:maven-idea-plugin:2.2:idea
      

      I can theoretically add something like this to the corporate pom, and it really helps:

      ...
                        <unCheckedPlugins>
                          <unCheckedPlugin>org.apache.maven.plugins:maven-idea-plugin</unCheckedPlugin>
                        </unCheckedPlugins>
      ...
      

      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.

      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:

      ...
                        <unCheckedPluginList>${my.unchecked.plugins}</unCheckedPluginList>
      ...
      

        Activity

        Hide
        brianfox brianfox added a comment -

        converted to a comma separated list

        Show
        brianfox brianfox added a comment - converted to a comma separated list

          People

          • Assignee:
            brianfox brianfox
            Reporter:
            Petr Kozelka
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: