maven-release-plugin - perform - maven release plugin tagnameformat

Maven release plugin y ventanas de línea rompe

Question

Cuando intento ejecutar el complemento de liberación de maven, cambia la versión en el archivo pom.xml. Antes del lanzamiento de Maven, cada línea que termina tiene un estilo Unix <lf> pero después de ejecutarlo en mi máquina Windows, el complemento cambia cada línea del archivo a <cr><lf> .

Mis preguntas son:

a) ¿Hay una manera de decirle a maven que deje todo como está o que use un final de línea específico?

o

b) ¿Hay una manera general de decirle a Windows cuál debería ser el final de la línea? Incluso una herramienta que piratea algo en el sistema operativo sería considerada útil.

Eché un vistazo a este https://issues.jfrog.org/jira/browse/BI-111 y dice "resuelto" pero estoy usando la última versión y no funciona para mí.

Answer 1

Hay cuatro soluciones posibles.

1. Utilice el complemento de montaje de Maven

Creo que la mejor idea es investigar el plugin de montaje de Maven . Debería permitirte actualizar el separador de línea. Consulte la section "fileSet" para más detalles.

2. Usa PowerShell para llamar a mvn

Como solución temporal, puede usar PowerShell (Inicio-> Todos los programas-> Accesorios-> Windows PowerShell). Llame a maven como lo haría, con algunos extras en doble cita de las declaraciones -D. mvn assembly:assembly -P prod "-Dmaven.test.skip=true" . Ahora agregue a este -Dline.separator = `n. Esto debería hacer que PowerShell agregue el valor de escape.

3. Escriba su propio complemento para anular "line.separator" antes de que se actualice el pom.

Siga la Guía de Maven para crear un complemento simple. Todo lo que necesita hacer es anular el valor. Configure el complemento para que se ejecute en la fase anterior a la modificación de pom.

System.getProperties().setProperty("line.separator", "/n");

4. Construir en una máquina virtual de Linux.

Existe una opción que no corrige el problema de compatibilidad de Windows, pero debería resolver su problema principal. Mira a crear un pequeño servidor de Linux VirtualBox. Una simple conexión NAT debería ser suficiente para el acceso a Internet. Instale Maven, Java, etc. en esta máquina. Construir sobre ella Debido a que es Linux, el separador de línea debe ser solo ''/ n''. La máquina virtual necesitaría 256 - 512 MB de RAM y 20 GB de espacio de almacenamiento (Linux + muchas posibles dependencias de Maven). Si terminas gustándote, incluso puedes expandirlo para alojar un producto de integración continua como Jenkins.

Answer 2

Mi solución es usar la propiedad SVN: svn:eol-style=native . Así que SVN "convierte" el pom.xml cuando se actualiza o confirma.

Answer 3

Trabajando en Linux, pero deseando los finales de línea de Windows en, por ejemplo, la salida de set-versions , esta solución rápida funciona para mí:

mvn -Dline.separator=$''/r/n'' /
    -DautoVersionSubmodules=true /
    -DdevelopmentVersion=1.2.3-SNAPSHOT /
    release:update-versions

Answer 4

Trabajo en Windows (CRLF) y uso terminaciones LF en mis archivos. Yo uso Git.

He elegido configurar core.autocrlf para la input . Según https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration input configuración de input es para esta situación:

Si está en un sistema Linux o Mac que usa finales de línea LF, entonces no quiere que Git los convierta automáticamente cuando retire los archivos; sin embargo, si un archivo con terminaciones CRLF se introduce accidentalmente, entonces es posible que desee que Git lo arregle. Puede decirle a Git que convierta CRLF a LF en la confirmación pero no al revés configurando core.autocrlf en input

Sin embargo, me funciona bien cuando estoy en Windows. Puedes intentarlo si tu situación es similar:

• Si el archivo CRLF se confirma en el repositorio, los finales de línea de CRLF serán visibles en el pago. Por lo tanto, uno puede reaccionar (p. Ej., Recordar a los colegas que presten atención a los finales de línea).
• El uso de Maven Release Plugin no hará que pom.xml se confirme con CRLF (será LF).

Abajo:

• La solución depende de la máquina. Uno puede olvidar verificar la configuración de Git antes de lanzar desde una máquina diferente, lo que hace que se confirme CRLF pom.xml.