Cómo recuperar el número de revisión de subversión actual y la URL con maven

Hago un checkout de alguna twig o label del repository de subversión y luego construyo el proyecto con maven.

Ahora, me gustaría get el número de revisión actual de la tienda y la URL de algún file. ¿Cómo puedo hacer eso? Es decir, me gustaría get el número de revisión y la URL de cualquier twig / label que haya realizado el pago.

Sé sobre buildnumber-maven-plugin pero creo que no hace esto. Obtiene el número de revisión de la bifurcación que se especifica en pom.xml.

La solución expuesta por user2990242 es ideal para la versión independiente (gracias por una buena explicación). Después de eso, solo tiene que agregar información en el file manifest.mf con el complemento maven-jar (o maven-war). aquí un ejemplo completo:

<plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>buildnumber-maven-plugin</artifactId> <version>1.3</version> <executions> <execution> <phase>validate</phase> <goals> <goal>create</goal> </goals> </execution> </executions> <configuration> <timestampFormat>{0,date,dd-MM-yyyy HH:mm:ss}</timestampFormat> <doCheck>false</doCheck> <doUpdate>false</doUpdate> <providerImplementations> <svn>javasvn</svn> </providerImplementations> </configuration> <dependencies> <dependency> <groupId>com.google.code.maven-scm-provider-svnjava</groupId> <artifactId>maven-scm-provider-svnjava</artifactId> <version>2.1.1</version> </dependency> <dependency> <groupId>org.tmatesoft.svnkit</groupId> <artifactId>svnkit</artifactId> <version>1.8.5</version> </dependency> </dependencies> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>2.5</version> <configuration> <archive> <manifest> <addClasspath>true</addClasspath> </manifest> <manifestEntries> <Implementation-Build>${buildNumber}</Implementation-Build> <Implementation-Title>${project.name}</Implementation-Title> <Implementation-Vendor>ENTERPRISE</Implementation-Vendor> <Implementation-Version>${project.version}</Implementation-Version> <Built-By>${user.name}</Built-By> <Built-OS>${os.name}</Built-OS> <Build-Date>${timestamp}</Build-Date> <SCM-Revision>${buildNumber}</SCM-Revision> </manifestEntries> </archive> </configuration> </plugin> 

Puede usar maven-antrun-plugin para ejecutar svnversion .

 <project> […] <build> <plugins> <plugin> <artifactId>maven-antrun-plugin</artifactId> <executions> <execution> <phase>package</phase> <configuration> <tasks> <exec executable="sh"> <arg value="-c"/> <arg value="svnversion &gt;version.txt" /> </exec> </tasks> </configuration> <goals> <goal>run</goal> </goals> </execution> </executions> </plugin> </plugins> </build> […] </project> 

NB: He usado sh -c para ejecutar svnversion, por lo que puedo networkingirigir la salida a un file. No creo que pueda get el resultado en una propiedad para que lo use la creación maven.

Puede usar el mismo enfoque para ejecutar svn info --url .

Como ya se dijo, el complemento Maven Build Number se puede usar para encontrar la revisión.

En cuanto a la URL: Maven Practice es ponerla en el POM usando la label <scm>. Si configura este derecho una vez y luego utiliza los plugins Maven correspondientes ( maven-scm-plugin , maven-release-plugin ) para ramificar, labelr, liberar, etc., puede estar seguro de que la label <scm> -tag siempre contiene la URL correcta .

buildnumber-maven-plugin inyecta solo la revisión actual en tu compilation para que tengas razón. Para get la URL, creo que debes escribir un plugin maven que use SVNKit .

Me parece que la API solo admite la ejecución del command 'svn' y sus diversos parameters e interruptores. El problema es que en subversión, se usa un command ejecutable diferente para recuperar un número de versión detallado apropiado, que es 'svnversion'. Usando este command, puedo decir si tengo una versión mixta, una versión modificada, etc. Por ejemplo:

 [jim@localhost sb_rc1 993]$ svn info | grep Revision Revision: 51159 [jim@localhost sb_rc1 994]$ svnversion 51159M [jim@localhost sb_rc1 994]$ 

¿Adivina qué? 'svn info' me está mintiendo aquí. Mi copy local se modifica desde el 51159 original, por lo que 'svnversion' informa el número de versión con una M adjunta. ¿Qué sucede si estoy experimentando con una twig que contiene una versión mixta? 'svnversion' puede manejar esto. 'svn info' no puede. Peor aún, como se muestra arriba, proporcionará información engañosa y potencialmente desastrosa si, por ejemplo, estoy basando una liberación de la mala información.

Ya ha dicho que esto no satisface sus necesidades, pero para otros que tienen un problema similar, vale la pena señalar que puede utilizar Maven SCM API para invocar commands SCM arbitrarios contra el repository configurado en la sección scm de su POM. Por ejemplo, en esta respuesta mostré cómo asignar un único file en un Maven mojo.

Puede modificar ese ejemplo ligeramente para, en cambio, SCMProvider el SCMProvider a SvnExeScmProvider e invocar su método info() . Esto devuelve un SvnInfoScmResult que envuelve un SvnInfoItem . El elemento encapsula los resultados de ejecutar un command svn info través de la API de Subversion estándar.

Para completar, antrun admite exportar properties de ant a mvn desde la versión 1.7. Consulte Agregar un nuevo parámetro para exportar las properties de Ant a las properties de Maven

Esta es una pregunta antigua, pero buildnumber-maven-plugin ahora expone un ${scmBranch} con la URL de SCM en él. Lo intenté brevemente y parece funcionar. Para utilizarlo en el filtrado de resources, primero tendrá que ponerlo en una propiedad, como con el valor de timestamp expuesto por Maven.

Ver http://mojo.codehaus.org/buildnumber-maven-plugin/usage.html para más información.

Buildernumber-maven-plugin dependientes en el cliente svn que instaló cuando "providerImplementations" no se especificó en la configuration del complemento. Cuando la ruta de ejecución svn no está definida en la ruta del sistema, o su versión del cliente svn no coincide, el complemento no puede llamar a la línea de command svn correctamente.

Entonces, agregar un cliente javasvn y su dependencia es una buena idea.

  <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>buildnumber-maven-plugin</artifactId> <version>1.2</version> <executions> <execution> <phase>validate</phase> <goals> <goal>create</goal> </goals> </execution> </executions> <configuration> <doCheck>false</doCheck> <doUpdate>false</doUpdate> <providerImplementations> <svn>javasvn</svn> </providerImplementations> </configuration> <dependencies> <dependency> <groupId>com.google.code.maven-scm-provider-svnjava</groupId> <artifactId>maven-scm-provider-svnjava</artifactId> <version>2.0</version> </dependency> <dependency> <groupId>org.tmatesoft.svnkit</groupId> <artifactId>svnkit</artifactId> <version>1.7.8</version> </dependency> </dependencies> </plugin>