Un buon posto per mettere automaticamente generato il codice?

Question

Abbiamo gruppo di classi generati automaticamente che sono per lo stub Axis2, scheletri ecc Per alcuni WSDL complicate, Axis2 genera una tonnellata di java in grano, alberi mozzi ecc e sono sicuro che ci sono altri casi anche quando si utilizza la generazione automatica.

Per ora trattiamo questi come altri membri di prima classe del nostro codice di base e sono immagazzinate nel pacchetto stesso.

Tuttavia quando si fa refactoring, pulizie ecc diventa difficile estirpare gli avvertimenti che vengono da queste classi auto-generate. Per esempio, se sto cercando di ripulire il codice in modo da utilizzare farmaci generici Java1.5, non v'è alcun buon modo per sapere quante di queste classi incriminate sono nostri vs essere generato automaticamente.

Dovrei separando queste parti generati automaticamente fuori in un pacchetto differente? Come fate a memorizzare tali artefatti nel repository?

EDIT: Vedo 'generano durante il processo di compilazione' in alcune risposte molto al di sotto. Mentre vedo i vantaggi di fare che, io non abbastanza vedo come posso uscire da una check-repository.

Il mio codice ha compilazione dipendenze temporali su alcuni di questi corsi e per me, un accumulo durante lo sviluppo è un 'ctrl-s' in Eclipse. Usiamo formica-script per generare la compilazione, eseguire i test e generare risultati finali.

Answer 1

È possibile mantenere gli stessi pacchetti, ma utilizzare una cartella di origine diversa (qualcosa come generato-src), che è quello che facciamo. In realtà sono sul recinto circa l'intera idea di salvare il codice generato nel repository del codice sorgente. Lo facciamo come vantaggio per gli altri sviluppatori sul progetto, ma di solito ha senso per rigenerare il codice sorgente, come parte del processo di generazione. Se il codice generato è improbabile che cambi, quindi utilizzando un progetto separato e generare un vaso potrebbe essere più pratico.

Answer 2

Sintesi delle migliori pratiche:

• Lo rendono ripetibile
  • Crea codice generato come parte di un processo di compilazione.
  • Non controllare il codice generato nel controllo del codice sorgente. (Fare il check-nella fonte. Ad esempio WSDL)
• Mantenere codice generato separato dal codice gestito
  • Utilizzare una cartella di origine diversa per l'output generato.
  • Fornire una .jar separato in modo che questo ha generato codice diventa una dipendenza.
  • Considerare l'utilizzo di un progetto IDE diverso (o modulo Maven)

Answer 3

Ho messo questi file in un progetto di loro. In questo modo, posso aggiungere il file di build, tutte le patch di cui ho bisogno, ecc in un unico luogo e spegnere tutte le avvertenze per il codice generato.

Answer 4

Se li stai controllando nel vostro sistema di controllo del codice sorgente, non . Farli ottenere ri-generati da un passaggio di generazione. Se vengono generati da un WSDL, il check-nel WSDL, non il codice risultante.

Mi consiglia di avere quel passaggio di generazione generare un .jar completamente separato per il codice generato, e quindi eliminando i file di origine, proprio per renderlo il più improbabile possibile che manutentori cercheranno di modificare a mano l'origine auto-generata.

In questo modo, le vostre attività di refactoring vedranno il codice generato automaticamente come come una libreria di terze parti invece di origine per essere manipolato.

Answer 5

Per ogni serie di artefatti generati, creare un nuovo progetto che esegue la generazione, quindi raggruppa i manufatti su nel JAR e file sorgente di avviamento postale, e poi fare riferimento dalla tua app. Mantiene le cose belle e separato, e sottolinea il fatto che gli artefatti generati non sono per cambiare dall'IDE.

Answer 6

con Maven e axistools-maven-plugin, le sorgenti generati sono posti in una cartella di origine diversa nella directory 'target'. questa directory di destinazione è dove Maven genera tutti i file e le cose, in modo che possa essere pulito.
Questo è molto conviniened, perché i file generati appare anche in una cartella di origine diversa entro l'IDE.