Allow explicit configured plugins to execute on master as well

[glimmerveen]

Extended the MasterPromoteExtension to not only retain the hardcoded gitflow-helper-maven-plugin itself and the maven-deploy-plugin, or the plugins related to explicit supplied command-line goals, but also allow a project to configure additional plugins that may also execute on master/support.

This serves two cases:

1. It solves the issue gitflow-helper-maven-plugin is not compatible with maven plugins that rewrite the POM file #127 (though admittedly it still would be more clean to be able to download the pom file from the release repo)
2. It can serve as a basic extension point to allow other "things" to happen on a master build, that are beyond the scope of deploying maven artifacts (ie have some antrun script run)

[glimmerveen]

Thanks @bvarner for merging this!

[rhierlmeier]

Thank you @glimmerveen for this PR.

In the following example the flatten-maven-plugin has two executions: flatten-in-master and flatten-other
Only the flatten-in-master should be executed in the master build.

Will this use case work with this PR?

<plugin>
  <groupId>org.codehaus.mojo</groupId>
  <artifactId>flatten-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>flatten-in-master</id>
      <goals>
        <goal>flatten</goal>
      </goals>
      <phase>process-resources</phase>
    </execution>
      <id>flatten-other</id>
      <goals>
        <goal>flatten</goal>
      </goals>
      <phase>process-resources</phase>
    </execution>
  </executions>  
</plugin>
<plugin>
  <plugin>
    <groupId>com.e-gineering</groupId>
    <artifactId>gitflow-helper-maven-plugin</artifactId>
    <configuration>
      <retainPlugins>
        <retainPlugin>org.codehaus.mojo:flatten-maven-plugin:flatten-in-master</retainPlugin>
      </retainPlugins>
    </configuration>
  </plugin>  
</plugin>

[glimmerveen]

Thank you @glimmerveen for this PR.

In the following example the flatten-maven-plugin has two executions: flatten-in-master and flatten-other Only the flatten-in-master should be executed in the master build.

Will this use case work with this PR?

In its current form no; it currently retains all executions of a plugin. I added this capability on top of existing logic that ensured that plugins activated through command line arguments would be retained. That existing logic centered around the idea that no plugins should be allowed to execute on master, and achieved that by removing complete Plugin 'activations'. This PR added a third way to retain plugins (on top of the default excludes, and command line activated plugins).

More fine-grained control is definitely possible, but being able to retain specific execution(s) may require a bit of refactoring of this logic.

[rhierlmeier]

Thank you. I created issue #136 for this feature.

[glimmerveen]

Thank you. I created issue #136 for this feature.

Based on your question I took the liberty to update the logic to support your use-case as well. See PR #137