Saltar al contenido

Compilar el módulo Maven con una versión diferente de Java

Solución:

Hay una serie de trucos para compilar código fuente con una versión del JDK diferente a la que está usando para ejecutar Maven, por ejemplo, puede usar algo como

<project>
  [...]
  <build>
    [...]
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.5.1</version>
        <configuration>
          <executable><!-- path-to-javac --></executable>
        </configuration>
      </plugin>
    </plugins>
    [...]
  </build>
  [...] 
</project>

El problema con este enfoque es que ahora ha codificado la ruta al JDK en su POM. Todo funcionará bien en tu maquina pero cuando tenga que reconstruir su máquina porque el disco duro falló, o cuando desee construir en una máquina diferente, se quedará atascado ya que es muy probable que la ruta no coincida.

Lo correcto mejores prácticas La forma de manejar esto es a través de Toolchains. Esto te verá creando un ~/.m2/toolchains.xml archivo que describe dónde se encuentran cada una de las diferentes cadenas de herramientas en su sistema. Luego, la versión del JDK puede ser aplicada por el complemento Maven Toolchains, p. Ej.

<plugins>
 ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-toolchains-plugin</artifactId>
    <version>1.0</version>
    <executions> 
      <execution>
        <phase>validate</phase>
        <goals>
          <goal>toolchain</goal>
        </goals>
      </execution>
    </executions>
    <configuration>
      <toolchains>
        <jdk>
          <version>1.6</version>
        </jdk>
      </toolchains>
    </configuration>
  </plugin>
  ...
</plugins>

Lo siguiente es que no necesita esto con tanta frecuencia como cree. Por ejemplo, utilizando el source y target valores, puede generar el código de bytes correcto para el JRE al que se dirige … el único problema que encontrará es el uso de métodos que son nuevos en JRE 1.7 … que es donde entra en juego Animal Sniffer Plugin de Mojo. Animal Sniffer se puede utilizar para asegurarse de que solo utilice los métodos del JRE al que se dirige. El consenso general de la comunidad es que el uso de source y target Las opciones de configuración en la configuración del complemento del compilador Maven junto con el uso de Animal Sniffer de Mojo prácticamente eliminan la necesidad de cadenas de herramientas en el extremo del compilador … en el extremo Surefire todavía hay necesidad de cadenas de herramientas … y tengo algunos casos extremos para los que necesito actualizar el complemento del compilador y los complementos de cadenas de herramientas para manejarlos, pero, de manera realista, no llegará a esos casos extremos 😉

Solo para asegurarse de que su pregunta original esté completamente respondida (ya que lo anterior responde a la pregunta que quería hacer, en lugar de la que hizo)

Actualmente está compilando con JDK 1.7 sin embargo dependiendo de la versión del complemento del compilador de Maven que esté utilizando, es posible que esté compilando con <source>1.4</source><target>1.4</target> o <source>1.5</source><target>1.5</target> a menos que haya cambiado la configuración del complemento del compilador de Maven en su pom.xml. Eso dictará qué características de lenguaje están disponibles para usted, pero no qué clases … por lo que estaría generando código que funcionará en JRE 1.7 y siempre que no haya utilizado ninguna clase / método nuevo introducido desde 1.4 / 1.5 (Tal como String.isEmpty()) también debería funcionar en JRE 1.4 / 1.5 … la única forma de estar seguro de si funciona en una JVM tan antigua es: ejecutarla en la antigua JVM O usar Animal Sniffer.

Cadenas de herramientas Maven

Para usar múltiples versiones de Java, necesita usar Maven Toolchains, que requiere que cree un toolchains.xml archivo en su ~/.m2 Carpeta Maven, que contiene todas las versiones de Java instaladas en su máquina:

<toolchains>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>Java13</id>
      <version>13</version>
    </provides>
    <configuration>
      <jdkHome>${env.JAVA_HOME_13}</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>Java9</id>
      <version>9</version>
    </provides>
    <configuration>
      <jdkHome>${env.JAVA_HOME_9}</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>Java8</id>
      <version>8</version>
    </provides>
    <configuration>
      <jdkHome>${env.JAVA_HOME_8}</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>Java7</id>
      <version>7</version>
    </provides>
    <configuration>
      <jdkHome>${env.JAVA_HOME_7}</jdkHome>
    </configuration>
  </toolchain>
  <toolchain>
    <type>jdk</type>
    <provides>
      <id>Java6</id>
      <version>6</version>
    </provides>
    <configuration>
      <jdkHome>${env.JAVA_HOME_6}</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

los JAVA_HOME_13, JAVA_HOME_9, JAVA_HOME_8, JAVA_HOME_7, JAVA_HOME_6 Las variables de entorno se configuran para que hagan referencia a la ruta donde está instalada la versión de Java asociada.

El archivo de configuración pom.xml principal de FlexyPool

El padre pom.xml El archivo de configuración de Maven del proyecto FlexyPool define la configuración global de la versión de Java

<properties>
    <jdk.version>8</jdk.version>
    ...
</properties>

Ahora, necesitamos instruir tanto al compilador como a los complementos de prueba para que usen la versión de Java configurada.

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-toolchains-plugin</artifactId>
            <version>1.1</version>
            <executions>
                <execution>
                    <goals>
                        <goal>toolchain</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <toolchains>
                    <jdk>
                        <version>${jdk.version}</version>
                    </jdk>
                </toolchains>
            </configuration>
        </plugin>
        
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>${maven-compiler-plugin.version}</version>
            <configuration>
                <source>${jdk.version}</source>
                <target>${jdk.version}</target>
                <showDeprecation>true</showDeprecation>
                <showWarnings>true</showWarnings>
            </configuration>
        </plugin>
        
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>${maven-surefire-plugin.version}</version>
        </plugin>
    </plugins>
</build>

El módulo secundario Maven de FlexyPool pom.xml usando una versión de Java diferente

los flexy-pool-core-java9 El módulo secundario de Maven que requiere una versión de Java diferente solo necesita anular el predeterminado jdk.version Propiedad de Maven:

<properties>
    <jdk.version>9</jdk.version>
</properties>

Y eso es todo, ahora podemos construir cada módulo usando su propia versión mínima viable de Java.

use la configuración para el JDK6 en su pom superior, será heredada por todo el módulo, y lo sobrescribirá para su pom de servidor con la configuración diferente requerida.

En cuanto a la ruta del JDK, puede especificarlo, consulte aquí: http://maven.apache.org/plugins/maven-compiler-plugin/examples/compile-using-different-jdk.html

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags : /

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *