La migliore posizione per i file ant build.xml?

Question

Per quelli di voi che usano Ant con più progetti, dove si mettono i file build.xml? Ne metti uno in ogni progetto o li metti in un progetto separato che contiene tutti i tuoi file relativi a Ant?

Il solito consiglio è di inserire un build.xml in ogni progetto. Ma questo ha alcuni inconvenienti:

• Rende difficile riutilizzare obiettivi comuni in più progetti.

• A volte si desidera utilizzare Ant per esportare un progetto dal controllo del codice sorgente e distribuirlo. Ovviamente non è possibile farlo se il file di build si trova nel progetto stesso.

Ma se li si mette in una posizione comune:

• gente ha bisogno di essere consapevoli della loro posizione di usarli; non possono semplicemente usare "ant -find" per trovare il file del progetto corrente.

• Non è possibile avere istruzioni di compilazione diverse per diversi rami del progetto.

Che cosa fate?

EDIT: Grazie per i buoni suggerimenti finora. Per quanto riguarda Maven, questi non sono progetti Java e ho l'impressione che Maven sia pensato solo per Java.

Answer 1

Inserire i file Ant con il progetto. Questo è il di fatto dello standard e raccomandato dal creatore di Ant. Cercherò di affrontare alcuni dei problemi che hai allevato:

• riutilizzo di obiettivi comuni dovrebbe essere fatto utilizzando tecniche come descritto da Eric Hatcher nel suo libro Java Development with Ant. Fondamentalmente, estrai tutti gli elementi comuni in alcuni file di livello superiore che "ereditano" tutti gli altri file Ant.

• Utilizzare Ant per esportare un progetto dal controllo del codice sorgente mi sembra strano, ma se si desidera eseguire questa operazione, utilizzare un file Ant diverso :-) È possibile creare un target come ant export -Dproject=foo/bar.

Per Formica, vi consiglio di afferrare quel libro - ha un sacco di tecniche utili.

La vera raccomandazione che vorrei fare è di abbandonare Ant e convertire su Maven - come ha fatto la Apache Software Foundation (mantengono sia Ant che Maven).

Answer 2

La mia regola empirica è di mettere il file build.xml nella directory in cui tutti i file sono referenziati. In altre parole, nessun percorso relativo dovrebbe iniziare con "../". Dove vivo, questo di solito significa metterlo nella directory "trunk", che ha sotto src, lib, build, docs, ecc.

Ciò rende i percorsi molto più puliti nel file e rende evidente come costruire il progetto.

Dove ho più progetti da compilare, creerò un build.xml separato per ogni progetto e un file build.xml centrale nella directory in cui sono presenti tutti gli altri file build.xml. Questo ti dà molta flessibilità con pochissimo lavoro.

Answer 3

Mi aspetto che un file di build Ant si trovi nella parte superiore di un progetto (è già un problema dover guardare un file di build per "scoprire" come costruire il progetto, quindi se devo individualo per primo, mi farà impazzire completamente). Ora, riguardo tutti gli inconvenienti che hai citato, sono tentato di dire: perché non usi Maven?

Answer 4

Il modo in cui ho fatto questo è nel passato (Ora mi basta usare Maven):

• Avere un build.xml nella radice di ogni progetto
• Crea un build.xml generale per tutti i progetti e posizionarlo nel il bagagliaio del mio repository
• Il file completo buid.xml ha attività di verifica per ogni progetto. Immagino che quando hai menzionato l'esportazione dal repository, tu intendi dire che l'importazione è stata effettivamente effettuata con il numero .
• Il file di configurazione generale anche definisce le dipendenze, se del caso
• È possibile aggiornare i singoli progetti utilizzando il file di configurazione di ogni singolo progetto
• Se si dispone di attività comuni definiti, si può ereditare da un file di configurazione comune e come qualcun altro ha suggerito.

Sembra che il tuo insieme di progetti possa essere un buon candidato per la migrazione a Maven, mi rendo conto che non è sempre possibile ma se hai tempo, potresti voler esaminarlo.

Answer 5

Se si lavora con progetti indipendenti, è possibile:

• mettete il vostro build.xml al livello più alto
• posto definizioni Ant comuni (Antlib) in un altro progetto (ad esempio config)
• uso svn: gli esterni di importare la definizione comune Antlib (da 'config') nel progetto

EDIT il trucco con svn: gli esterni è che se si collega all'HEAD di alcuni file comuni, può succedere che cambieranno dopo un paio di mesi/anni. Quindi, ogni volta che taggate, dovreste cambiare lo svn: esterni per puntare a una versione di correzione del progetto incluso. Questo può tornare utile quando un progetto deve essere ricostruito anni dopo la sua ultima creazione.