title: Maven install/deploy with Jenkins build number
body: <p><strong>UPDATE #1 9/18</strong></p>
  
  <p>My company has decided to entirely revamp their development/release cycle to fit a growing number of developers.</p>
  
  <p>The git process will be similar to the <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow">successful branching model</a> with a few changes. Instead of developers having direct push access to the "develop" branch, developers would need to make a merge/pull request, requiring code review and basic unit testing.</p>
  
  <p>The version system would be Major.Minor.Patch, where Major versions mark backwards compatibility breaks, Minor versions mark new features and minor bug fixes, and Patch marks critical hot fixes. This new version system will remove the Jenkins build number as a useful piece of information, but attach it to the deployed artifacts for historical purposes.</p>
  
  <p>The "develop" branch will be tracked by Jenkins to build and deploy a SNAPSHOT to our local Nexus, so unreleased but accepted features are available to the developers. The "master" branch will also be tracked by Jenkins to build and deploy release artifacts.</p>
  
  <p>The release process would:</p>
  
  <ul>
  <li>Update the POM version based on the released features</li>
  <li>Git tag the branch with the new version</li>
  <li>Perform unit, integration, and system testing.</li>
  <li>Build, obfuscate, and deploy the release artifacts to our Nexus</li>
  <li>Update the "develop" branch version to "Major.Minor++-SNAPSHOT" for the new development SNAPSHOT.</li>
  </ul>
  
  <p><strong>ORIGINAL POST</strong></p>
  
  <p>I am attempting to build a JAR library that is obfuscated, uses a dynamic build number based on a Jenkins/Hudson build, and is deployed to an in-house Sonatype Nexus.</p>
  
  <p>My issue is that Maven install/deploy does not honor changes to finalName, and setting the version with an expression like the following is considered "bad practice":</p>
  
  <pre><code>    &lt;version&gt;1.0.${buildNumber}&lt;/version&gt;
  </code></pre>
  
  <p>Despite this being bad practice, it properly installs/deploys the artifacts with the proper version, both local and remote. The build number is based off of a pair of profiles that are linked to the existence of the build number environment variable of a Jenkins build system, and defaults to 0 in the absence of that variable:</p>
  
  <pre class="lang-xml prettyprint-override"><code>    &lt;profile&gt;
          &lt;id&gt;static_build_number&lt;/id&gt;
          &lt;activation&gt;
              &lt;property&gt;
                  &lt;name&gt;!env.BUILD_NUMBER&lt;/name&gt;
              &lt;/property&gt;
          &lt;/activation&gt;
          &lt;properties&gt;
              &lt;buildNumber&gt;0&lt;/buildNumber&gt;
          &lt;/properties&gt;
      &lt;/profile&gt;
      &lt;profile&gt;
          &lt;id&gt;dynamic_build_number&lt;/id&gt;
          &lt;activation&gt;
              &lt;property&gt;
                  &lt;name&gt;env.BUILD_NUMBER&lt;/name&gt;
              &lt;/property&gt;
          &lt;/activation&gt;
          &lt;properties&gt;
              &lt;buildNumber&gt;${env.BUILD_NUMBER}&lt;/buildNumber&gt;
          &lt;/properties&gt;
      &lt;/profile&gt;
  </code></pre>
  
  <p>We do not use SNAPSHOT versions, as any version that is committed and pushed to the Nexus is considered a tested release version.</p>
  
  <p>Is there a "proper" way to set the Maven version based on a Jenkins/Hudson dynamic build number, allowing it to be deployed with that updated version?</p>