I am using mvn buildNumber plugin to generate build no with latest svn revision no. But, our version is not resolve to ${buildNumber} in the duration of installing in .m2 local reposotry.

here is the our pom details:

<modelVersion>4.0.0</modelVersion>
 <groupId>com.hp.cloudprint</groupId>
 <artifactId>testutils</artifactId>
 <name>testutils</name>
 <version>6.3.rel.${buildNumber}</version>
 <description>This jar contains some helper classes which can simplify the writing of JUnit test cases.</description>
 <dependencies>

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>buildnumber-maven-plugin</artifactId>
    <executions>
     <execution>
      <id>useLastCommittedRevision</id>
      <phase>validate</phase>
      <goals>
       <goal>create</goal>
      </goals>
     </execution>
    </executions>
    <configuration>
     <doCheck>false</doCheck>
     <doUpdate>true</doUpdate>
     <getRevisionOnlyOnce>true</getRevisionOnlyOnce>
    </configuration>
   </plugin>
<scm>
  <connection>scm:svn:https://acn-platform</connection>
  <developerConnection>scm:svn:https://abc-platform/trunk</developerConnection>
 </scm>.
</project>

Building jar: C:\Documents and Settings\hpadmin\workspace\testutils\target\testutils-6.3.rel.2930.jar [INFO] [install:install] [INFO] Installing C:\Documents and Settings\hpadmin\workspace\testutils\target\testutils-6.3.rel.2930.jar to C:\Documents and Settings\jhab.m2*\repository\com\hp\cloudprint\testutils\6.3.rel.${buildNumber}\testutils-6.3.rel.${buildNumber}.jar** [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL Target generated correct jar. testutil-6.3.rel.2297.jar*

Thanks in advance

Binit

link|improve this question
feedback

1 Answer

I quitted about that, but, I really preferred not having got it, think in the consecuences!

I am using artifactory and, if you use that scheme, you wont get updated dependencies under distinct numbers.

Let's see.
I have a.jar with version 2.3.1-SNAPSHOT, if I modify that product, other products will take advance of my changes. This wont happen with ${buildNumber}, and you would have to change every product dependencies to point the newer one. (Ok, there's a maven artifact for that, but I dont like that philosofy).

If you still want something like buildNumber, and you are using hudson, you may use ${BUILD_NUMBER}, a Hudson internal variable.

I am still tuning my release process, my last plan is:

  • Version is clean: 3.2.1 or 3.2.1-SNAPSHOT
  • finalName contains everything, name-version-scmbuild-hudsonbuild
  • Build version and Hudson build number in manifest
  • (program)A bean will recover info from manifest and publish it to web, for debugging purposes.
  • Hudson publish to artifactory using artifactory plugin instead built-in scm mechanism. It will be published using only version, so older artifacts will be rewritten.
  • Hudson publish every build to a ftp, with its final name, there won't be overrides.
  • Artifactory will give you some information about builds.

When you release your product: Maven release:

  • checks that no dependency is snapshot
  • Tags your code to new release
  • Increment your version number

When recovering a version because of a bug or misfunctionallity

  • In the manifest you have version, scmbuild and hudsonbuild, you can put your svn or cvs to that build to reproduce.
  • You are taking your old releases from artifactory
  • You may see your hudson and sonar statistics from that version
  • As your product was released, its code is not only in build number, but in tagged scm.

I am fairly keen to keep this conversation open to everybody suggestion.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown