2012-07-23-maven-release-gitflow.html (5882B)
1 <!DOCTYPE html> 2 <html lang="en"> 3 <head> 4 <!-- Sep 03, 2024 --> 5 <meta charset="utf-8" /> 6 <meta name="viewport" content="width=device-width, initial-scale=1" /> 7 <title>Maven Release Gitflow</title> 8 <meta name="author" content="Vincent Demeester" /> 9 <meta name="generator" content="Org Mode" /> 10 <link rel='icon' type='image/x-icon' href='/images/favicon.ico'/> 11 <meta name='viewport' content='width=device-width, initial-scale=1'> 12 <link rel='stylesheet' href='/css/new.css' type='text/css'/> 13 <link rel='stylesheet' href='/css/syntax.css' type='text/css'/> 14 <link href='/index.xml' rel='alternate' type='application/rss+xml' title='Vincent Demeester' /> 15 </head> 16 <body> 17 <main id="content" class="content"> 18 <header> 19 <h1 class="title">Maven Release Gitflow</h1> 20 </header><section id="outline-container-Introduction" class="outline-2"> 21 <h2 id="Introduction">Introduction</h2> 22 <div class="outline-text-2" id="text-Introduction"> 23 <p> 24 I like a lot the <a href="http://nvie.com/posts/a-successful-git-branching-model/">gitflow</a> way of managing project. When working on maven project, there is 25 few great plugins that helps to get the work done. One of them is <a href="http://maven.apache.org/plugins/maven-release-plugin">maven-release-plugin</a>. 26 </p> 27 28 <p> 29 Inspired on this <a href="https://gist.github.com/1043970">gist</a>, I’ve come 30 with a cool way of doing things (let say we want to release a 0.1 31 version of an artifact) : 32 </p> 33 </div> 34 </section> 35 <section id="outline-container-prepare-the-pom.xml." class="outline-2"> 36 <h2 id="prepare-the-pom.xml.">Prepare the pom.xml.</h2> 37 <div class="outline-text-2" id="text-prepare-the-pom.xml."> 38 <p> 39 It needs <code><scm></code> entries, <code><distributionManagement></code> entries (to know 40 where to deploy the release artifact) and few options for the 41 maven-release-plugin : 42 </p> 43 44 <p> 45 {{< highlight xml >}} 46 </p> 47 <div class="org-src-container"> 48 <pre class="src src-xml"><project> 49 50 <!-- […] --> 51 <build> 52 <plugins> 53 <!-- […] --> 54 <plugin> 55 <groupId>org.apache.maven.plugins</groupId> 56 <artifactId>maven-release-plugin</artifactId> 57 <version>2.3.2</version> 58 <configuration> 59 <tagNameFormat>v@{project.version}</tagNameFormat> 60 <pushChanges>false</pushChanges> 61 <localCheckout>true</localCheckout> 62 </configuration> 63 </plugin> 64 <!-- […] --> 65 </plugins> 66 </build> 67 <!-- […] --> 68 69 </project> 70 </pre> 71 </div> 72 73 <p> 74 Few explanation here : 75 </p> 76 77 <ul class="org-ul"> 78 <li><code>tagNameFormat</code> is here to change the default tag name (which is 79 <code>${project.artifactId}-${project.version}</code>) to a better one.</li> 80 <li><code>pushChanges</code> set to <code>false</code> tells maven-release-plugin not to push 81 changes (this will become useful)</li> 82 <li><code>localCheckout</code> set to <code>true</code> tells maven-release-plugin to clone from 83 local repository (not distant). This is especially useful here because 84 we didn’t push anything (so not setting this option would result in a 85 failure).</li> 86 </ul> 87 </div> 88 </section> 89 <section id="outline-container-the-real-stuff" class="outline-2"> 90 <h2 id="the-real-stuff">The real stuff</h2> 91 <div class="outline-text-2" id="text-the-real-stuff"> 92 <p> 93 First create a release branch from develop. 94 </p> 95 96 <div class="org-src-container"> 97 <pre class="src src-bash">$ git checkout -b release/v0.1 develop 98 </pre> 99 </div> 100 101 <p> 102 Then run the maven release stuff. 103 </p> 104 105 <div class="org-src-container"> 106 <pre class="src src-bash">$ mvn release:prepare # change the pom, commit and tag version, and 107 # re-change pom (by incrementing SNAPSHOT version) 108 $ mvn release:perform # get the tagged version, compile and deploy 109 </pre> 110 </div> 111 112 <p> 113 And the real fun begins. 114 </p> 115 116 <div class="org-src-container"> 117 <pre class="src src-bash">$ git checkout develop # get back to the develop branch 118 $ git merge --no-ff release/v0.1 # merge the version back into develop 119 $ git checkout master # go to the master branch 120 $ git merge --no-ff release/v0.1~1 # merge the version back into master but 121 # the tagged version instead of the release/v0.1 HEAD 122 $ git branch -D release/v0.1 # Removing the release branch 123 $ git push --all && git push --tags # Finally push everything 124 </pre> 125 </div> 126 127 <p> 128 The real magic here is the <code>git merge --no-ff release/v0.1~1</code> which will 129 merge into master the commit before the HEAD of the branch 130 <code>release/v0.1</code>. 131 </p> 132 133 <p> 134 The next step would be to create a helper script that automates this and 135 verify that the <code>pom.xml</code> has the right configuration options. 136 </p> 137 138 <p> 139 <b>Edit 17:58</b> : You can take a look <a href="https://github.com/vdemeester/java-config/blob/master/bin/mvn-release-flow">here</a> 140 </p> 141 </div> 142 </section> 143 </main> 144 <footer id="postamble" class="status"> 145 <footer> 146 <small><a href="/" rel="history">Index</a> • <a href="/sitemap.html">Sitemap</a> • <a href="https://dl.sbr.pm/">Files</a></small><br/> 147 <small class='questions'>Questions, comments ? Please use my <a href="https://lists.sr.ht/~vdemeester/public-inbox">public inbox</a> by sending a plain-text email to <a href="mailto:~vdemeester/public-inbox@lists.sr.ht">~vdemeester/public-inbox@lists.sr.ht</a>.</small><br/> 148 <small class='copyright'> 149 Content and design by Vincent Demeester 150 (<a rel='licence' href='http://creativecommons.org/licenses/by-nc-sa/3.0/'>Some rights reserved</a>) 151 </small><br /> 152 </footer> 153 </footer> 154 </body> 155 </html>