Dovrebbe Maven generare il codice java JAXB o semplicemente usare il codice Java dal controllo del codice sorgente?

Abbiamo una situazione simile qui, ma gli schemi non cambiano così spesso che Java non ha bisogno di essere rigenerato molto spesso.

Il modo in cui ci occupiamo di questo è creare un nuovo progetto Maven con solo i file di schema come sorgente e generare il codice Java da quello. Quindi distribuiamo Java generato come jar in un repository Nexus locale, ma le sole cose che entrano nel controllo del codice sorgente sono il file POM, i file di schema e qualsiasi altro file necessario (come i file di binding) . Tutti i progetti che richiedono Java generato ottenerlo come dipendenza, da Nexus.

Quando lo schema cambia, le modifiche vengono archiviate nel controllo del codice sorgente, un nuovo jar viene generato e distribuito su Nexus. Qualsiasi progetto che richiede la nuova versione può semplicemente aggiornare le dipendenze per utilizzare il nuovo numero di versione.

Il build server non deve generare nulla e le librerie sono disponibili per tutti i team, come dipendenze nei loro progetti.

La nostra motivazione a farlo in questo modo era che spesso molti altri team hanno bisogno del Java generato per applicazioni indipendenti, e che una volta che gli schemi si stabilizzano, solitamente rimangono stabili e non hanno bisogno di essere rigenerati con ogni build / rilascio.

I file generati non devono essere controllati nel controllo del codice sorgente (related: P.SE: Controllo o meno il codice generato nel controllo del codice sorgente? SO Devo memorizzare codice generato nel controllo sorgente ). Il codice generato da jaxb rientra sicuramente in questa categoria.

La logica si riduce per lo stesso motivo per cui non si controllano i file oggetto nel controllo del codice sorgente o la build finale stessa. Sono l'output programmatico di qualche altro processo.

Il contenuto del controllo del codice sorgente dovrebbe essere sufficiente per eseguire una compilazione da un dato punto nel tempo. Questo può includere il file .xsd come parte del contratto che viene fornito per l'API (proprio come si farebbe per archiviare i file .h per una libreria nel mondo C).

Avere generato il codice sorgente nel controllo del codice sorgente porta alla tentazione di modificarlo e diventa qualcosa che non puoi generare di nuovo. Qualcun altro non può prendere jaxb e generare la stessa cosa.

La fonte generata si scontra anche con il principio DRY. Le informazioni necessarie per crearlo sono nel .xsd e nel passo di costruzione. L'aggiunta dei file di classe che vengono generati è un'altra copia di queste informazioni senza alcun valore aggiunto.

Dai due punti sopra, renditi conto che cambiare la sorgente generata significa (a volte necessario a volte) significa che il codice sorgente non corrisponde più alla definizione - non corrisponde a .xsd (o se si tratta di una grammatica, la fonte non corrisponde più alla definizione del linguaggio). Considerare l'incubo quando l'applicazione viene portata da una lingua all'altra e si genera l'origine da .xsd e la funzionalità del codice generato non corrisponde a quella del codice generato (e ottimizzato).

A volte, la sorgente generata può essere molto grande al punto di qualcosa che è proibitivamente costoso da inserire nel controllo del codice sorgente. Aneddoto: Apache Axis una volta ha generato per me un file .java da 4 megabyte (sì, 4 megabyte di testo) - Non volevo davvero che fosse qualcosa di simile nell'albero dei sorgenti (la maggior parte degli IDE ha dato di matto per qualcosa di così massiccio).

Quindi no, non controllare la fonte generata. Dovresti avere solo ciò di cui hai bisogno per creare una build e i passaggi per farlo.