¿Cuál es la mejor manera de almacenar la información de la versión de Subversion en EAR?

StackOverflow https://stackoverflow.com/questions/171828

  •  05-07-2019
  •  | 
  •  

Pregunta

Cuando recibo un informe de error o un mensaje no funciona, una de mis preguntas iniciales es ¿qué versión? Dado que las compilaciones diferentes se encuentran en muchas etapas de prueba, planificación y despliegue, a menudo es una pregunta no trivial.

En el caso de la publicación de archivos Java JAR (ear, jar, rar, war), me gustaría poder mirar en / JAR y cambiar a la misma rama, versión o etiqueta que fue la fuente de la versión publicada. JAR.

¿Cómo puedo ajustar mejor el proceso de compilación ant para que la información de la versión en el svn checkout permanezca en la compilación creada?

Estaba pensando en la línea de:

  • agregando un archivo VERSION, pero ¿con qué contenido?
  • almacenar información en el archivo META-INF, pero ¿bajo qué propiedad con qué contenido?
  • copiando fuentes en el archivo de resultados
  • agregó svn: propiedades a todas las fuentes con palabras clave en lugares donde el compilador las deja ser

Terminé usando el enfoque de svnversion (la respuesta aceptada), porque escanea todo el subárbol en lugar de svn info, que solo mira el archivo / directorio actual. Para esto, definí la tarea SVN en el archivo ant para que sea más portátil. 

<taskdef name="svn" classname="org.tigris.subversion.svnant.SvnTask">
  <classpath>
    <pathelement location="${dir.lib}/ant/svnant.jar"/>
    <pathelement location="${dir.lib}/ant/svnClientAdapter.jar"/>
    <pathelement location="${dir.lib}/ant/svnkit.jar"/>
    <pathelement location="${dir.lib}/ant/svnjavahl.jar"/>
  </classpath>        
</taskdef>

No todas las compilaciones dan como resultado servicios web. El archivo ear antes de la implementación debe permanecer con el mismo nombre debido a la actualización en el servidor de aplicaciones. Hacer que el archivo sea ejecutable sigue siendo una opción, pero hasta entonces solo incluyo un archivo de información de la versión. 

<target name="version">
  <svn><wcVersion path="${dir.source}"/></svn>
  <echo file="${dir.build}/VERSION">${revision.range}</echo>
</target>

Refs:
svnrevision: http://svnbook.red-bean.com/en/1.1/re57 .html
svn info http://svnbook.red-bean.com/en/1.1/re13 .html
subclipse svn task: http://subclipse.tigris.org/svnant/svn.html
svn client: http://svnkit.com/

¿Fue útil?

Solución

Use el comando svnversion en su script Ant para obtener el número de revisión: 

<exec executable="svnversion" outputproperty="svnversion" failonerror="true">
  <env key="path" value="/usr/bin"/>
  <arg value="--no-newline" />
</exec>

Luego usa la propiedad $ {svnversion} en algún lugar de tu EAR. Lo colocamos en el nombre del archivo EAR, pero también puede ponerlo en un archivo readme o version dentro del EAR, o especificar la versión en el META-INF / manifest.mf del EAR: 

<!-- myapp-r1234.ear -->
<property name="ear" value="myapp-r${svnrevision}.ear" />

Otros consejos

Desearía proporcionar la sucursal y el número de repositorio de Subversion. Como se discutió en ¿Cómo acceder al número de compilación actual de Subversion? , el comando svn info le proporcionará esta información, que luego puede usar para crear un archivo VERSION o colocarlo en cualquiera de los otros archivos que está incorporando en sus archivos * AR. Si no tiene nada más en mente, podría considerar usar la tarea XmlProperty Ant para extraer la información relevante de la salida de su svn & nbsp; info & nbsp; - comando xml

Consulte el jreleaseinfo . Contiene una tarea ANT que puede generar una clase java a la que se puede llamar en tiempo de ejecución para mostrar la información de lanzamiento de su proyecto.

Me gusta su simplicidad.

Consulte también esta pregunta: Numeración de compilación y versión para proyectos Java (ant, cvs, hudson)

Incluye varios fragmentos de código útiles.

Desde lo alto de mi mente. ¿Una etiqueta para cada construcción jar?

Tenemos la primera parte de nuestra compilación para crear un archivo version.txt en la raíz del paquete y volcar la etiqueta utilizada para verificar el código de (en nuestro caso) CVS ... Además, la parte final de nuestro el proceso de compilación comprueba el EAR completamente integrado en CVS para futuras referencias.

De esa manera, si tenemos un problema con una aplicación web, es solo un caso de pedirle al reportero que presione /app/version.txt, desde allí podemos profundizar en el historial de compilación particular en CVS para localizar los componentes relevantes ( maneja diferentes versiones de bibliotecas en aplicaciones) para localizar el error.

No estoy seguro de cuánta ayuda es para nuestro personal de soporte, pero definitivamente es algo de lo que se quejan de que no está allí

Realice compilaciones automáticas y coloque una etiqueta (con un sello de fecha) en la base de código cuando la compilación sea exitosa (con un curso de prueba de unidad).

En su proceso de entrega, solo entregue compilaciones etiquetadas al cliente. De esta forma, usted tiene el control y puede colocar el nombre de la etiqueta en un archivo readme.txt en algún lugar, o hacer que el nombre del archivo del archivo ear refleje el nombre de la etiqueta.

Personalmente volví a CVS, y esta es una de las razones. En CVS, puedo tener un informe de clase que es la etiqueta. Todos mis archivos jar contienen un " main " lo que los hace ejecutables. Con preguntas de soporte, le pido al cliente que haga un " java -jar somejar.jar " y envíame la salida junto con la pregunta.

De esta manera estoy seguro de la compilación que están usando, e incluso puedo tener información como la versión de Java, el tipo de SO y la versión. Sin que el cliente tenga que responder preguntas extrañas.

Es simple pero muy efectivo.

¿Por qué no poner el número de compilación en un archivo de propiedades ... esto puede ser fácilmente leído por Java y enviado a una Ayuda | Acerca del diálogo (applet / aplicación), pie de página web o cualquier otra GUI que pueda tener.

(Vea el pie de página en cada página SOF ... tiene el número de versión de SVN allí).

¿Parece una carga más fácil que buscar en el WAR / EAR / JAR, etc., tiempo fácil?

Almaceno la revisión absoluta del repositorio como parte de mi número de versión completo. Esto le da a la gente un vistazo rápido para ver si un cambio dado está en una versión determinada o no.

También almacenamos el número de versión / fecha de compilación / etc. en el archivo de manifiesto de la oreja como propiedades personalizadas, en su mayoría solo informativas. También lo almacenamos en un archivo de propiedades que está integrado en nuestro archivo jar, para que la aplicación pueda leerlo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top