Maven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
git-flow, maven, maven-release-plugin
Solution
No, you can't bind to a plugin to another plugin. Only to a phase.
In Maven-internal terms, a "Mojo" is the thing that does work. A "plugin" is a collection of mojos wrapped up so you can reference them from the POM. Mojos bind to phases only.
From the plugin development documentation:
Each Mojo specified inside a plugin descriptor must provide the following
...
phase ... Defines a default phase to bind a mojo execution to if the user does not explicitly set a phase in the POM. Note: This annotation will not automagically make a mojo run when the plugin declaration is added to the POM. It merely enables the user to omit the `<phase>` element from the surrounding `<execution>` element.
For further confirmation, see the source of MojoExecution (the JavaDoc for this class isn't helpful) and notice that there are two possible sources of execution enumerated:
An execution that originates from the direct invocation of a goal from the CLI
and
An execution that originates from a goal bound to a lifecycle phase
No other way to kick off an execution means you're out of luck (barring extraordinary measures like rolling your own plugin that combines the effects of the two plugins you want to link and then using your custom plugin).
Problem
Note regarding the accepted answer: I accepted the answer because of strong circumstantial evidence. Nonetheless, this is circumstantial evidence, so take it with a grain of salt. How can I have a plugin be triggered when the user runs a plugin goal, not a lifecycle phase? (This has been asked before, but the answer was to use a lifecycle phase.) Case in point: I need `release:branch` to invoke `regex-plugin` to generate a branch with the current version as its name, minus the -SNAPSHOT suffix. This is what I have, which requires the developer to activate a profile and invoke the `verify` phase. I need the developer to simply invoke `release:branch`, which in turn should cause `regex-plugin` to run. In a bit of a marriage to Gitflow. ``` <profile> <id>Release Branch</id> <build> <plugins> <!-- On validate, compute the current version without -SNAPSHOT. --> <!-- Put the result in a property. --> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>1.7</version> <executions> <execution> <phase>validate</phase> <goals> <goal>regex-property</goal> </goals> <configuration> <value>${project.version}</value> <regex>^(.*)-SNAPSHOT$</regex> <replacement>$1</replacement> <name>project.unqualifiedVersion</name> </configuration> </execution> </executions> </plugin> <!-- Also on validate, run the branch plugin, and use --> <!-- the non-SNAPSHOT version thus computed in the branch name. --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.3.2</version> <executions> <execution> <phase>validate</phase> <goals> <goal>branch</goal> </goals> <configuration> <branchName>release/${project.unqualifiedVersion}</branchName> <updateWorkingCopyVersions>true</updateWorkingCopyVersions> <updateBranchVersions>false</updateBranchVersions> </configuration> </execution> </executions> </plugin> </plugins> </build> </profile> ``` The intent is for `release:branch` to move the current snapshot version (say, `1.0.5-SNAPSHOT`) into a new branch, which should be named after the version but without the superfluous `-SNAPSHOT` suffix (`1.0.5`). The current branch should then take on a new snapshot version (`1.1.0-SNAPSHOT`, not `1.0.6-SNAPSHOT`, because we want release `1.0.x` to have room for hotfixes, so we reserve it for the branch) (I don't have the automatic computation of the next snapshot version figured out yet, so, if you run the Maven configuration above with `validate`, you will have to enter it at a prompt).