Diferencia de plugins Maven JAXB

He determinado que existen dos plugins de JAXB para Maven 2, con algunas configuraciones diferentes.

El uno es de Sun: http://jaxb.dev.java.net/jaxb-maven2-plugin/ , el otro de Mojohaus: http://mojohaus.org/jaxb2-maven-plugin/

¿Cuál de estos dos complementos se puede recomendar?


Gracias Matt. En mi pequeño proyecto de investigación, descubrí que hay bastante otro complemento que proviene de los domadores:

com.sun.tools.xjc.maven2 maven-jaxb-plugin 

y ese:

 org.jvnet.jaxb2.maven2 maven-jaxb2-plugin 

y aún el de Codehouse.

Vamos a resumir. Tenemos:

  1. el complemento maven-jaxb2 ( https://github.com/highsource/maven-jaxb2-plugin )
  2. el plugin maven-jaxb ( https://jaxb.dev.java.net/jaxb-maven2-plugin/ )
  3. el jaxb2-maven-plugin ( https://github.com/mojohaus/jaxb2-maven-plugin )

Basado en los comentarios de este hilo , siempre he usado el plugin maven-jaxb2 (es decir, el plugin n. ° 1):

Con respecto al org.jvnet.jaxb2.maven2: maven-jaxb2-plugin versus com.sun.tools.xjc.maven2: maven-jaxb-plugin, desde mi punto de vista es definitivamente el primero ( http: // maven-jaxb2 -plugin.java.net/ ).

Este complemento tiene muchas más características que com.sun.tools.xjc.maven2: maven-jaxb-plugin, el desarrollo está activo. Finalmente, soy uno de los autores 🙂 y yo diría que nos mantenemos en contacto con los desarrolladores y usuarios de JAXB y reactjsmos a las últimas características / solicitudes.

Y, de hecho, el complemento # 2 no está muy activo (¿está muerto?). Y porque siempre he estado contento con el n. ° 1, nunca he usado el plugin n. ° 3, así que no puedo decir nada al respecto. Por si acaso, aquí hay una configuración funcional para el complemento n. ° 1:

  ...    true org.apache.maven.plugins maven-compiler-plugin  1.5 1.5    org.jvnet.jaxb2.maven2 maven-jaxb2-plugin    generate        

Recientemente probé los tres complementos mencionados anteriormente (incluidos aquí también):

  1. el plugin maven-jaxb2 ( http://maven-jaxb2-plugin.java.net/ )
  2. el plugin maven-jaxb ( https://jaxb.dev.java.net/jaxb-maven2-plugin/)
  3. el jaxb2-maven-plugin ( http://mojo.codehaus.org/jaxb2-maven-plugin/ )

Terminé usando una cuarta opción: el complemento Maven de CXF XJC http://cxf.apache.org/cxf-xjc-plugin.html

Si me falta algo que quisiera saber, la configuración parecía más directa para lo que estaba tratando de hacer y más fácilmente me permitía ocuparme de la generación de clases duplicadas dentro del mismo espacio de nombres, similar a esta pregunta: ¿Hay algún problema? forma de tratar con las definiciones de elementos duplicados en varios archivos .xsd en JAXB? .

Ahora tengo control granular sobre cada XSD entrante y el correspondiente paquete de Java; Aquí hay una configuración de muestra cercana a la que estoy usando.

   org.apache.cxf cxf-xjc-plugin 2.3.0   org.apache.cxf.xjcplugins:cxf-xjc-dv:2.3.0     generate-sources generate-sources  xsdtojava   ${basedir}/target/generated-sources/src/main/java   src/main/resources/schema/commands.xsd  com.foo.bar.commands   src/main/resources/schema/responses.xsd com.foo.bar.responses       

Soy el autor de maven-jaxb2-plugin .

El plugin maven-jaxb2 actualmente usa JAXB 2.1. En las próximas versiones también proporcionaremos las versiones JAXB 2.0 y JAXB 2.2.

En cuanto a la discusión de “qué plugin es mejor”, verifique las características , decida usted mismo. Avíseme si pierde alguna funcionalidad.

  • maven-jaxb2-plugin utiliza la implementación de referencia JAXB por Oracle / Sun
  • cxf y jaxb2-maven-plugin usan Apache Xerces

En una ligera tangente: hubo un problema con el uso de maven-jaxb2-plugin con Eclipse Indigo que publiqué aquí . Una corrección (extensión) ha estado disponible recientemente.

Esto no pretende estar en desacuerdo, en absoluto, con la recomendación de maven-jaxb2-plugin sobre maven2-jaxb-plugin. No lo sé, pero espero que maven2-jaxb-plugin tenga el mismo problema, probablemente sin resolver.

Supongo que uno es para la especificación JAXB original y el codehaus es para la especificación JAXB 2.1 (y si dev.java.net cargara algo de tiempo este siglo, podría decirlo con certeza).