tutorial pom plugin español compiler comandos central artefact java maven jaxb java-9 jigsaw

pom - ¿Cómo expresar la dependencia en maven de las características de Java ee para la transición a Java 9?



maven-compiler-plugin pom (4)

Usamos maven y tenemos artefactos que a su vez dependen de otros artefactos internos. Estoy en el proceso de migrar a java-9 , y tengo la intención de migrar todo a Java 9 primero sin modularizar el código (es decir, en el módulo sin nombre).

El problema con el que me encuentro es que dependemos de java.xml.bind , que ahora no está incluido en los módulos predeterminados. ¿Hay una forma "correcta" de expresar esta dependencia en java.xml.bind con Maven?

Bien, espero que esto ayude a alguien. Si, por casualidad, ha instalado Java 9 o 10 y descubre que no puede superar este error javax.xml.bind , tal vez esté utilizando Java 8 a través de jenv por carpeta (realmente lamento ser tan vago , pero, eso es todo lo que tengo tiempo por el momento)?

Pero agregar una configuración correcta para JAVA_HOME solucionó mi problema: export JAVA_HOME="$(/usr/libexec/java_home -v 1.8)" en MacOS.

El Sistema de módulos habla de la forma en que los módulos sin nombre, como en el caso de cargar la aplicación desde classpath, construyen el gráfico del módulo. Además, de la documentación misma: -

Cuando el compilador compila código en el módulo sin nombre, o se invoca el lanzador de Java y la clase principal de la aplicación se carga desde la ruta de clase en el módulo sin nombre del cargador de clases de la aplicación, entonces el conjunto predeterminado de módulos raíz para el módulo sin nombre se calcula de la siguiente manera:

  • El módulo java.se es una raíz, si existe. Si no existe, entonces cada módulo java.* En la ruta del módulo de actualización o entre los módulos del sistema que exports al menos un paquete, sin calificación, es una raíz.

  • Cada módulo non-java.* En la ruta del módulo de actualización o entre los módulos del sistema que exports al menos un paquete, sin calificación, también es una raíz.

De lo contrario, el conjunto predeterminado de módulos raíz depende de la fase:

  • En el momento de la compilación, generalmente es el conjunto de módulos que se está compilando (más sobre esto a continuación);

  • En el momento del enlace está vacío; y

  • En tiempo de ejecución, es el módulo principal de la aplicación, como se especifica a través de la --module (o -m para abreviar).

En ocasiones, es necesario agregar módulos al conjunto raíz predeterminado para garantizar que la plataforma, la biblioteca o los módulos de proveedor de servicios específicos estén presentes en el gráfico del módulo. En cualquier fase la opción

--add-modules <module>(,<module>)* donde <module> es un nombre de módulo, agrega los módulos nombrados al conjunto predeterminado de módulos raíz.

Un problema similar se enfrentó en jetty.project donde un thread de la lista de correo jdk discutió sobre el mismo y la solución fue usar:

--add-modules java.se.ee

que les proporcionó acceso a todos los módulos de Java SE y en su caso simplemente será:

--add-modules java.xml.bind

Para usar esto en maven, puede incrustar lo mismo en el maven-compiler-plugin usando

<compilerArgs> <arg>--add-modules</arg> <arg>java.xml.bind</arg> </compilerArgs>

como lo sugiere ZhekaKozlov here .

Un punto importante a tener en cuenta es que marcar la desaprobación de una API también significa que probablemente quieras evitar usarla. Para adaptarse a esta forma, probablemente pueda comenzar a consumir la dependencia de jaxb-api:2.3.0 que ahora se puede cargar como un módulo y también se puede ejecutar desde el classpath. El cambio que debe hacer es agregar lo siguiente a su lista de dependencias:

<dependency> <groupId>javax.xml.bind</groupId> <artifactId>jaxb-api</artifactId> <version>2.3.0</version> </dependency>

Actualización : - Eventualmente, con Java-10 ya fuera y JDK / 11 a continuación, lo ideal sería seguir el enlace a JEP 320: elimine los módulos Java EE y CORBA y reemplace aún más esas dependencias con sus bibliotecas independientes.

JAXB, junto con las otras API compartidas con Java EE (JAX-WS, JAF, JTA y las llamadas "Anotaciones comunes") están en desuso en Java SE 9 y se propone eliminarlas en una versión futura de Java SE y el JDK Cada una de estas API tiene una versión / descarga independiente. Cada API tiene su propio JSR que también lo mantiene. La transición de las API incluidas en el JDK a las versiones independientes será, por supuesto, un poco perjudicial.

Un primer paso para eliminar estas API de Java SE y el JDK es no resolver los módulos que contienen estas API de forma predeterminada. Cuando compila o ejecuta código en la ruta de clase con JDK 9, inicialmente parecerá que las API no existen. Una solución rápida, como se señaló en otra respuesta, es compilar o ejecutar con --add-modules java.xml.bind . Esa opción de CLI agrega el módulo "java.xml.bind" al conjunto de módulos raíz para resolver al inicio y funciona con JDK 9 porque este módulo está incluido en la imagen de tiempo de ejecución de JDK.

Más allá de la solución rápida, las aplicaciones o bibliotecas que usan JAXB deberán pasar a usar la versión independiente de la API / implementación. JAXB 2.3.0 se publicará pronto en Maven Central e incluye los cambios para trabajar con JDK 9 y versiones posteriores. La versión independiente se puede implementar en la ruta de clase como otros archivos JAR. Eventualmente será posible implementar la versión independiente en la ruta del módulo (actualización) y usarla también como módulo. La Guía de migración de JDK 9 tendrá más información sobre las opciones para migrar código que usa JAXB u otras API compartidas con Java EE.

Sí, debe pasar --add-modules al compilador de Java:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.7.0</version> <configuration> <release>9</release> <compilerArgs> <arg>--add-modules</arg> <arg>javax.xml.bind</arg> </compilerArgs> </configuration> </plugin>

Entonces su proyecto debe compilarse bien.