tag rama que para name conectar con como commits commands comentarios cambiar git maven mavanagaiata

que - Obtención de la versión de artefacto de maven de la rama de git



git tag name (6)

¿Has probado usar este complemento ?: https://github.com/ktoso/maven-git-commit-id-plugin . Puede configurarlo para generar un archivo de propiedades con toda la información relevante sobre su estado de repos:

  • rama
  • describir
  • commitId
  • buildUserName
  • buildUserEmail
  • Tiempo de construcción
  • commitUserName
  • commitUserEmail
  • commitMessageShort
  • commitMessageFull
  • commitTime

Tenemos un requisito de flujo de trabajo que esencialmente significa que necesitamos tener la versión de artefacto de un módulo definido externamente desde la rama actual en git.

Es decir, si estamos en la rama principal en git, necesito <version>master-...</version> y si estamos en la rama bugfixX, necesito <version>bugfixX-....</version> para el artefacto generado para este pom.xml.

Anteriormente descubrí que https://github.com/koraktor/mavanagaiata puede proporcionar el hash SHA-1 como una propiedad y de la documentación se desprende que también puede proporcionar la rama, por lo que tal vez podría ejecutarse con la antelación suficiente. el proceso podría establecer la propiedad y simplemente poner <version>${our.version}</version> en el pom. Si esto es posible, me gustaría mucho ver un pom.xml de trabajo (y recompensar una recompensa de 500 puntos por él también).

Si no, creo que estamos en preprocesamiento o "git checkout" hacemos magia extra con algunos de los ganchos (que aún no he probado, el código de trabajo sería genial también).

Tenemos un pom de nivel superior, que se puede ejecutar para generar un archivo de propiedades en "..." antes de compilar los módulos donde esta funcionalidad sobre la que estoy preguntando debe ir.

¿Alguna sugerencia sobre cómo resolver esto?

¿Has revisado el buildnumber-maven-plugin que te da la oportunidad de usar el número de revisión de git. Pero necesitabas algo diferente. Además, sugeriría hacer algo como:

1.0.0-SNAPSHOT 1.0.0-SNAPSHOT

estar en el maestro

en una rama puede simplemente cambiar la versión a

1.0.0-BF-SNAPSHOT

De hecho, Maven no puede cambiar la versión de su propio proyecto en una carrera con otros objetivos. Además, hasta donde yo sé, Maven no admite propiedades arbitrarias en la etiqueta <version> . Por lo tanto, se requiere una ejecución por separado para ejecutar un objetivo que cambiará la versión del POM. Hay varios complementos que pueden hacerlo, para este caso uno puede usar las versions:set objetivo desde el plugin de versions - http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html

Por lo tanto, uno podría ejecutarlo de la siguiente manera, por ejemplo:

mvn versions:set -DgenerateBackupPoms=false -DnewVersion=$branch-SNAPSHOT

donde la variable $branch debe contener el nombre de la sucursal actual de Git; se puede extraer con git rev-parse , así:

branch=$(git rev-parse --abbrev-ref HEAD)

Pero aún así, uno tiene que ejecutarlo de alguna manera. Puedes hacerlo manualmente, pero es engorroso. Entonces, supongo que de hecho la solución más sólida sería abordar esto desde el lado de Git. Eso es - un gancho de Git. Aquí está el gancho completo de Git post-checkout que hará el trabajo (el mismo código que el anterior con algunos filtros para ejecutar el enganche solo cuando se desprotege la sucursal, no solo los archivos individuales):

#!/bin/bash echo ''Will change the version in pom.xml files...'' # check if the checkout was to checkout a branch if [ $3 != ''1'' ] then echo ''git checkout did not checkout a branch - quitting'';exit fi # get current branch name branch=$(git rev-parse --abbrev-ref HEAD) version=$branch-SNAPSHOT # run maven versions plugin to set new version mvn versions:set -DgenerateBackupPoms=false -DnewVersion=$version echo ''Changed version in pom.xml files to $version''

Coloque este contenido en el archivo PROJECTDIR/.git/hooks/post-checkout . Tenga en cuenta que el archivo hook debe ser ejecutable para ejecutarlo ( chmod +x post-checkout ).

Pocas notas sobre el plugin de versions : es bastante flexible y admite muchas opciones y tiene algunos otros objetivos que pueden ser de ayuda, dependiendo de la estructura de su proyecto (¿utiliza o no padres pompones, los niños tienen sus propias versiones o derivan de padre, etc.). Por lo tanto, el gancho anterior podría modificarse ligeramente para respaldar su caso específico utilizando otros objetivos del plugin de versions o especificando parámetros adicionales.

Pros:

  • Robusto
  • No es necesario cambiar nada en los archivos pom.xml para que esto funcione
  • Esta "funcionalidad" se puede desactivar simplemente desactivando el gancho (eliminar o hacer que no sea ejecutable) - de nuevo, no se requieren cambios en el pom.xml

Contras:

  • No se puede obligar a otros a usar un gancho: se debe instalar manualmente después de clonar el repositorio (o puede proporcionar un guión para instalar el anzuelo si supuestamente los usuarios de Git tienen miedo de tocar el material dentro del directorio .git).

ACTUALIZAR

De ahora en adelante es la versión más complicada del gancho, que no solo configurará la versión para el nombre de la rama, sino que también conservará el sufijo de la versión anterior. Por ejemplo, si se proporciona la versión anterior master-1.0-SNAPSHOT , el cambio a la rama feature1 cambiará la versión del proyecto a feature1-1.0-SNAPSHOT . Este script bash sufre pocos problemas (requiere nombres de ramas sin el símbolo del guión ( - ) en el nombre, y solo toma la versión de la raíz pom), pero puede dar una idea de cómo se puede extender el gancho: dada una mezcla de mvn y comandos bash puedes extraer y actualizar bastante información en el POM.

#!/bin/bash echo ''Will change the version in pom.xml files...'' # check if the checkout was to checkout a branch if [ $3 != ''1'' ] then echo ''git checkout did not checkout a branch - quitting'';exit fi # get current branch name branch=$(git rev-parse --abbrev-ref HEAD) # get current version of the top level pom current_version=$(mvn help:evaluate -Dexpression=project.version | grep -v ''/[.*'') # extract version suffix suffix=$(echo $current_version | cut -d /- -f 2) # build new version version=$branch-$suffix # run maven versions plugin to set new version mvn versions:set -DgenerateBackupPoms=false -DnewVersion=$version echo ''Changed version in pom.xml files to $version''

Descargo de responsabilidad: soy el autor

Después de la extensión de maven core se administrará (prácticamente establecerá) la versión de forma dinámica en función de la rama o etiqueta actual desprotegida. Puede configurar patrones de versión personalizados como desee.

https://github.com/qoomon/maven-branch-versioning-extension

Ejemplo de formato de versión

Lamento revivir esta pregunta y publicar muy recientemente otra solución, pero es posible cambiar dinámicamente la versión de maven y usar algunas funciones de git, un poco como lo haría git describe .

El proyecto que hace esto es jgitver-maven-plugin (descargo de responsabilidad; yo soy el autor) , usa jgitver una biblioteca basada en jgit para derivar la versión del proyecto de maven de la información de git.

Es muy fácil de usar como una extensión de maven

... <build> <extensions> <extension> <groupId>fr.brouillard.oss</groupId> <artifactId>jgitver-maven-plugin</artifactId> <version>0.1.0</version> </extension> </extensions> ... </build> ...

La extensión también se puede usar como una extensión de complemento, y luego permite más configuración, por ejemplo, en caso de que no quiera utilizar SNAPSHOTS. Consulte la página del jgitver-maven-plugin para obtener una descripción de los escenarios de uso completo.

También hay un jgitver-maven-plugin disponible que hace más o menos lo mismo.

[editar 1] : respuesta al comentario de Thorbjørn Ravn Andersen

El complemento no modifica los archivos pom originales o los archivos build.gradle.
Para el complemento maven, las modificaciones se realizan tanto en la memoria en el Modelo de objetos maven y se escriben en un archivo temporal en el directorio temporal. El cálculo se basa solo en los metadatos de git (tags, commits, ...).
Esta no modificación permite no contaminar el historial de git. Cuando estés satisfecho con un commit de git, etiquetarlo con la git tag -a xyz y mvn deploy : eso es todo.
La versión en sus archivos de proyecto, ahora es inútil y se puede establecer en 0, por ejemplo.

A partir de hoy, y debido a IDEA-155733 solo las versiones EAP recientes de IntelliJ funcionan con el plugin maven. Eclipse y Netbeans no tienen ningún problema.

Si es suficiente establecer la etiqueta git y la información de la versión en el nombre del archivo del artefacto, puede usar maven-jgit-buildnumber-plugin :

<build> <finalName>${artifactId}-${git.buildnumber}</finalName> <plugins> <plugin> <groupId>ru.concerteza.buildnumber</groupId> <artifactId>maven-jgit-buildnumber-plugin</artifactId> <version>1.2.7</version> <executions> <execution> <id>git-buildnumber</id> <goals> <goal>extract-buildnumber</goal> </goals> <phase>prepare-package</phase> </execution> </executions> </plugin> <!-- more plugins --> </plugins> </build>