¿Debería Maven generar código Java JAXB o simplemente usar código Java desde el control de código fuente?

7

Estamos intentando planificar cómo combinar un servidor de compilación para nuestro nuevo y brillante backend de Java. Usamos mucha generación de código JAXB XSD y me metí en una discusión acalorada con quien le importaba que el servidor de compilación debería:

  1. Eliminar las estructuras creadas por JAXB que se registraron.
  2. Genere el código de XSD's.
  3. Use el código generado a partir de esos XSD.

Todos los demás pensaron que tenía más sentido simplemente usar el código que verificaron (verificamos el código generado desde el XSD porque Eclipse casi te obliga a hacer esto hasta donde puedo decir).

Mi único argumento antiguo está en mi lectura de prueba de Joel es que hacer la compilación en un solo paso significa la generación a partir del código fuente y el código fuente no es la fuente de Java, sino la XSD porque si se está confundiendo con el código generado, eventualmente lo pellizcarán.

Entonces, dado que todos estamos de acuerdo (es posible que no estén de acuerdo), probablemente deberíamos estar controlando nuestros archivos Java generados, ¿deberíamos usarlos para generar nuestro código o deberíamos generarlo utilizando los XSD?

    
pregunta Peter Turner 11.06.2014 - 19:38

2 respuestas

6

Aquí tenemos una situación similar, pero los esquemas no cambian tan a menudo, por lo que no es necesario que Java se regenere con mucha frecuencia.

La forma en que lo manejamos es crear un nuevo proyecto de Maven con solo los archivos de esquema como fuente y generar código Java a partir de eso. Luego implementamos el Java generado como un jar en un repositorio Nexus local, pero las cosas solo que entran en el control de origen son el archivo POM, los archivos de esquema y cualquier otro archivo necesario (como los archivos de enlace) . Cualquier proyecto que requiera el Java generado lo obtiene como una dependencia, de Nexus.

Cuando el esquema cambia , los cambios se incorporan al control de origen, se genera un nuevo archivo jar y se implementa en Nexus. Cualquier proyecto que requiera la nueva versión puede simplemente actualizar las dependencias para usar el nuevo número de versión.

El servidor de compilación no tiene que generar nada y las bibliotecas están disponibles para que lo usen todos los equipos, como dependencias en sus propios proyectos.

Nuestra motivación para hacerlo de esta manera era que a menudo muchos otros equipos necesitan el Java generado para aplicaciones independientes, y que una vez que los esquemas se estabilizan, por lo general se mantienen estables y no necesitan regenerarse. con cada compilación / lanzamiento.

    
respondido por el FrustratedWithFormsDesigner 11.06.2014 - 19:52
4

Los archivos generados no deben incluirse en el control de código fuente (relacionado: P.SE: ¿Verifico el código generado en control de fuente o no? SO Debo almacenar el código generado en control de fuente ). El código generado por jaxb ciertamente cae en esta categoría.

La lógica cae por la misma razón por la que no ingresas los archivos de objetos en el control de código fuente o en la compilación final. Son el resultado programático de algún otro proceso.

El contenido del control del código fuente debería ser suficiente para hacer una compilación desde cualquier punto dado en el tiempo. Este puede incluir el .xsd como parte del contrato que se le otorga para la API (de la misma forma en que uno registraría los archivos .h para una biblioteca en el mundo C).

El hecho de haber generado el código fuente en el control del código fuente lleva a la tentación de modificarlo y se convierte en algo que no se puede volver a generar. Alguien más no puede tomar jaxb y generar lo mismo.

La fuente generada también corre contra el principio DRY. La información necesaria para compilarla se encuentra en .xsd y en el paso de compilación. Agregar los archivos de clase que se generan es otra copia de esta información sin valor agregado.

A partir de los dos puntos anteriores, tenga en cuenta que cambiar los medios de origen generados (aunque a veces es necesario) significa que el código fuente ya no coincide con la definición, no coincide con .xsd (o si se trata de una gramática, la fuente ya no coincide con la definición de idioma). Considere la pesadilla cuando la aplicación se traslada de un idioma a otro y genera la fuente desde .xsd y la funcionalidad del código generado no coincide con la del código generado (y modificado).

A veces, la fuente generada puede ser muy grande hasta el punto de tener un costo prohibitivo para poner en el control del código fuente. Anécdota: Apache Axis una vez generó un archivo .java de 4 megabytes para mí (sí, 4 megabytes de texto). Realmente no quería que eso quedara en el árbol de origen (la mayoría de los IDE se asustaron por algo tan masivo).

Así que no, no verifique la fuente generada. Solo debes tener lo que necesitas para hacer una compilación y los pasos para hacer esa compilación.

    
respondido por el user40980 12.06.2014 - 00:08

Lea otras preguntas en las etiquetas