Antecedentes: estamos configurando la versión actual del proyecto como entorno del sistema:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.19.1</version>
    <configuration>
        <forkMode>always</forkMode>
        <environmentVariables>
            <project.target>${project.build.outputDirectory}</project.target>
            <project.version>${project.version}</project.version>
        </environmentVariables>
    </configuration>
</plugin>

Y luego obtenemos el valor en la prueba usando System.getenv("project.version"); y esto funciona bien en todas las máquinas ... excepto en una.

La máquina problemática es la nueva instancia de AWS EC2 con Ubuntu 16.04 LTS. La configuración y la configuración se ve bien. Verifiqué tanto OpenJDK como OracleJDK, últimas versiones, también verifiqué las versiones incluidas java y maven:

$ java -version
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

Maven

$ mvn -version
Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-1049-aws", arch: "amd64", family: "unix"

Y el más nuevo disponible para descargar:

$ mvn --version
Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 2017-10-18T07:58:13Z)
Maven home: /usr/share/maven
Java version: 1.8.0_161, vendor: Oracle Corporation
Java home: /usr/lib/jvm/jdk1.8.0_161/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-1049-aws", arch: "amd64", family: "unix"

Y el problema persiste. Lo extraño es que la bifurcación está habilitada (requerida) y la entrada del registro muestra que las variables se están configurando:

[DEBUG] Setting environment variable [project.version]=[4.0.0-SNAPSHOT]

Luego tenemos ejecución de prueba con bifurcación:

[DEBUG] boot(compact) classpath:  surefire-booter-2.19.1.jar  surefire-api-2.19.1.jar  test-classes  classes  junit-4.10.jar  hamcrest-core-1.1.jar  …-4.0.0-SNAPSHOT.jar  surefire-junit4-2.19.1.jar

Línea de comando de bifurcación: / bin / sh -c cd / mnt / ebsVolume /

Y sin embargo, System.getenv("project.version"); devuelve nula

2
Wojtek 6 mar. 2018 a las 23:45

3 respuestas

La mejor respuesta

Creo que necesita usar systemPropertyVariables en su lugar. Vea los documentos aquí.

    <systemPropertyVariables>
        <project.target>${project.build.outputDirectory}</project.target>
        <project.version>${project.version}</project.version>
    </systemPropertyVariables>
3
ilooner 7 mar. 2018 a las 04:19

Tal vez no sea la respuesta a la pregunta planteada, pero como otros usuarios como yo están leyendo este hilo, esto podría ser útil: descubrí que configurar una variable solo funciona si aún no está configurada (al menos en mi sistema Windows 10), es decir la variable debe estar desarmada con excludedEnvironmentVariables antes de ser aplicada. Ejemplo:

  • FOOBAR ya está configurado en el entorno en C:\test.conf
  • El complemento surefire está intentando establecerlo en un valor diferente:
    <environmentVariables>
        <FOOBAR>${project.build.directory}/test.conf</FOOBAR>
    </environmentVariables>
  • Se necesita <excludedEnvironmentVariables>FOOBAR</excludedEnvironmentVariables> para establecer el valor deseado; de lo contrario, se utiliza el del entorno.
0
k_o_ 9 abr. 2020 a las 03:13

Acabo de tener el mismo problema al llevar un proyecto de Fedora a Linux Mint. Ejecuté las mismas pruebas infinitas veces en Fedora, macOS, Windows 7 y Windows 10, nunca tuve ningún problema. Así que me sorprendió verlos fallar haciendo mvn test en la línea de comando bash. Se volvió aún más extraño verlos pasar cuando fueron ejecutados con el intellij test-runner. Ejecutar test desde la ventana de la herramienta Maven dentro de intellij falló nuevamente.

El enfoque systemPropertyVariables de @ ilooner funcionó, pero luego tuve que reemplazar las variables de entorno con las propiedades del sistema y usar System.getProperty() en lugar de System.getenv(). Esto no fue posible en mi caso.

La configuración siempre fue OpenJDK 11, junit5 y Maven 3.6.x con surefire-plugin 3.0.0-M3. Pero este no es el problema aquí. El problema es el nombre de la variable. Traté de definirlo directamente en el shell para ver si la prueba lo vería y esto sucedió:

$ export project.version=42
bash: export: `project.version=42': not a valid identifier

¡Resultó que desde bash 3 no puedes definir una variable de entorno que contenga un .! No importa si cygwin, macOS o Linux. Como se indica en Caracteres permitidos en nombres de variables de entorno Linux, debe pegar letras mayúsculas, dígitos y guiones bajos. Esto parece ser solo una recomendación y no para todos los shells, pero nunca se sabe dónde se ejecutará su aplicación algún día.

De vuelta a tu pregunta. Si usa PROJECT_TARGET en lugar de project.target, lo más probable es que funcione. En mi configuración actual también funcionó con project_target, pero esto podría causar problemas en otros lugares.

Sin embargo, no tengo respuesta, por qué el plugin surefire maneja variables.with.dots en Fedora 30, macOS Mojave y cygin, pero no en Mint 19.2 ni Ubuntu 18.4. . Los dos últimos usan bash 4.4 mientras que los dos primeros bash 5.0. Por lo tanto, podría estar conectado a la versión bash. Windows permite puntos, por lo que parece lógico que funcione allí. Pero aún así, no tiene sentido probar environment.variables.with.dots, porque en algunos sistemas simplemente no existen. Si quieres mantenerte portátil, debes evitarlos.

0
rstolle 22 sep. 2019 a las 05:55