Databases
StackOverflow2013
Postsdbo
POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
    primarykey
    data
    text
    <p><strong>Note regarding the accepted answer:</strong> I accepted the answer because of strong circumstantial evidence. Nonetheless, this is circumstantial evidence, so take it with a grain of salt.</p> <hr> <p>How can I have a plugin be triggered when the user runs a plugin goal, not a lifecycle phase? (This <a href="https://stackoverflow.com/questions/1393691/how-to-bind-a-plugin-goal-to-another-plugin-goal">has been asked</a> before, but the answer was to use a lifecycle phase.)</p> <p>Case in point: I need <code>release:branch</code> to invoke <code>regex-plugin</code> to generate a branch with the current version as its name, <em>minus the -SNAPSHOT suffix</em>. This is what I have, which requires the developer to activate a profile and invoke the <code>verify</code> phase. I need the developer to simply invoke <code>release:branch</code>, which in turn should cause <code>regex-plugin</code> to run. In a bit of a marriage to Gitflow.</p> <pre><code>&lt;profile&gt; &lt;id&gt;Release Branch&lt;/id&gt; &lt;build&gt; &lt;plugins&gt; &lt;!-- On validate, compute the current version without -SNAPSHOT. --&gt; &lt;!-- Put the result in a property. --&gt; &lt;plugin&gt; &lt;groupId&gt;org.codehaus.mojo&lt;/groupId&gt; &lt;artifactId&gt;build-helper-maven-plugin&lt;/artifactId&gt; &lt;version&gt;1.7&lt;/version&gt; &lt;executions&gt; &lt;execution&gt; &lt;phase&gt;validate&lt;/phase&gt; &lt;goals&gt; &lt;goal&gt;regex-property&lt;/goal&gt; &lt;/goals&gt; &lt;configuration&gt; &lt;value&gt;${project.version}&lt;/value&gt; &lt;regex&gt;^(.*)-SNAPSHOT$&lt;/regex&gt; &lt;replacement&gt;$1&lt;/replacement&gt; &lt;name&gt;project.unqualifiedVersion&lt;/name&gt; &lt;/configuration&gt; &lt;/execution&gt; &lt;/executions&gt; &lt;/plugin&gt; &lt;!-- Also on validate, run the branch plugin, and use --&gt; &lt;!-- the non-SNAPSHOT version thus computed in the branch name. --&gt; &lt;plugin&gt; &lt;groupId&gt;org.apache.maven.plugins&lt;/groupId&gt; &lt;artifactId&gt;maven-release-plugin&lt;/artifactId&gt; &lt;version&gt;2.3.2&lt;/version&gt; &lt;executions&gt; &lt;execution&gt; &lt;phase&gt;validate&lt;/phase&gt; &lt;goals&gt; &lt;goal&gt;branch&lt;/goal&gt; &lt;/goals&gt; &lt;configuration&gt; &lt;branchName&gt;release/${project.unqualifiedVersion}&lt;/branchName&gt; &lt;updateWorkingCopyVersions&gt;true&lt;/updateWorkingCopyVersions&gt; &lt;updateBranchVersions&gt;false&lt;/updateBranchVersions&gt; &lt;/configuration&gt; &lt;/execution&gt; &lt;/executions&gt; &lt;/plugin&gt; &lt;/plugins&gt; &lt;/build&gt; &lt;/profile&gt; </code></pre> <p>The intent is for <code>release:branch</code> to move the current snapshot version (say, <code>1.0.5-SNAPSHOT</code>) into a new branch, which should be named after the version but without the superfluous <code>-SNAPSHOT</code> suffix (<code>1.0.5</code>). The current branch should then take on a new snapshot version (<code>1.1.0-SNAPSHOT</code>, not <code>1.0.6-SNAPSHOT</code>, because we want release <code>1.0.x</code> 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 <code>validate</code>, you will have to enter it at a prompt).</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USMihai Danila
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
      1. USomer schleifer
      1. VTFavorite
    2. VO
      singulars
      1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
      1. USkryger
      1. VTFavorite
    1. COI second your remark that it cannot be done, but I'm waiting to be surprised :)
      singulars
      1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
      1. USSander Verhagen
    2. COYeah, it doesn't look good. Here's another answer claiming that it's not doable: http://stackoverflow.com/a/15185774/1569108. Sounds like a job for a custom lifecycle, or maybe I should take this away from Maven entirely and use something like Ant instead, since Maven is so unfriendly with this scenario. If they had a dummy phase that always runs, even when we only run a plugin goal, that would have been enough to solve this problem without headaches.
      singulars
      1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
      1. USMihai Danila
    3. COThe entire Maven release plugin may even be goals that you'd normally not bind to lifecycle phases. As such they may've been designed exclusively with passing parameters on the command-line along in mind. Oddly enough, the `prepare` goal supports `preparationGoals`, that sounds like what you'd want for the `branch` goal.
      singulars
      1. POMaven: Bind plugin execution to the execution of another plugin, not to a lifecycle phase
      1. USSander Verhagen
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload