Ant/Ivy per la costruzione del progetto

Question

Sto pensando di cambiare un progetto Maven che gestisco con Apache-Ant/Ivy. Ho bisogno di più controllo sul processo di compilazione e mi sento molto frustrato con Maven. Per favore non commentare su quanto sia grande Maven. La mia domanda riguarda Ivy.

Vorrei creare un modello di build Ant "standard" che possa essere successivamente utilizzato per altri progetti con modifiche minime.

Creerò un repository "enterprise" centrale in cui possiamo posizionare librerie di terze parti che non sono disponibili nei repository Maven pubblici (ad esempio librerie commerciali, librerie Sun, librerie proprietarie, ecc.). Questo archivio aziendale sarà disponibile sulla nostra LAN locale, ma potrebbe non essere disponibile al di fuori dell'ufficio.

Ogni sviluppatore avrà un archivio privato in ~/.ivy/repository. Mi piacerebbe che la build Ant aggiornasse automaticamente questo repository privato con le versioni modificate delle librerie dal repository enterprise.

In ~/.ivy/ant, ho intenzione di inserire i moduli "standard" per includere nei singoli file di progetto build.xml, utilizzando l'attività include in Ant 1.8. Questi moduli forniranno cose come Scala e Clojure destinazioni di compilazione con versioni diverse per diverse versioni di Scala e Clojure (es .: scala-compile-2.9.1.xml, clojure-compile-1.3.xml, ecc.) I moduli di compilazione saranno disponibili nel repository aziendale e dovrebbero essere aggiornati automaticamente nei repository privati ​​se loro cambiano

Ogni progetto seguirà un Maven struttura standard di directory: ${project}/src/main/java, ${project}/target/classes, ecc

In passato, ho provato con Ivy, ma la Formica costruire file ottenuto di essere molto grande (> 500 linee per la compilazione del modello file) e difficile da gestire/modificare. Spero che mettendo obiettivi standard nei loro moduli di compilazione nella directory ~/.ivy/ant, posso evitare che il codice aumenti.

Questo può essere fatto? Sono lontano dalla base? L'unica documentazione che riesco a trovare su Ivy è sul sito web di Apache (http://ant.apache.org/ivy). C'è qualche altra documentazione disponibile, inclusi i libri?

Answer 1

Un'idea piuttosto ragionevole sulla divisione del file di build del modello in file di supporto inclusi. Personalmente, ora sto passando a un progetto molto grande dalla formica (niente gestione delle dipendenze - solo copia dei file da ftp) alla soluzione ant/edy. Così ho fatto in questo modo - ho un file con obiettivi cardine - cioè pronto per la compilazione, compilato, pronto per l'archiviazione, archiviato - così via. Penso che tu abbia avuto l'idea. Ho configurato le dipendenze di tutti questi obiettivi (dipendenze in termini di formiche, non fraintendetemi). In questo modo - compilato dipende da pronto per la compilazione, pronto per compilare dipende da inizializzato - smth come questo. Questi obiettivi non hanno un corpo - sono per includere in ogni file di costruzione di ogni modulo del tuo progetto multi-modulo. L'unico scopo di questi obiettivi per il mantenimento dello STATO di build, a causa di questa importazione, le cose diventano piuttosto complicate ed è difficile sapere quale obiettivo è stato superato e quando questo obiettivo verrà eseguito. Ma con questo file posso facilmente cambiare lo stato di vy build su ogni pietra miliare sensata. Voglio in un modulo compilare i file di aiuto con exteran exe. Nessun problema: in questo progetto lo faccio e basta: il pronto per l'archiviazione dipende dall'obiettivo di compilare la guida. E dato che questi obiettivi sono inclusi - posso ignorarne solo alcuni - tutti gli altri preserebbero il modo desiderato di costruire un progetto.

Un'altra parte della mia strategia - i file di configurazione mixins - per ogni area specifica. Quindi ho un file per edera. Lì ho messo l'inizializzazione, la risoluzione, la pubblicazione e così via. Quando voglio usare edera - includo semplicemente questo file e gestisco le dipendenze attraverso i miei obiettivi cardine.Se la build è tipica, includo solo questo file e ho una funzionalità di convenzione sulla configurazione. Tutto pronto per l'uso. Come?? Semplicemente combinato con altri mixin. Le miscele possono includere altre miscele per dipendere da esse. Quindi ogni mixin è una parte riutilizzabile della mia strategia di costruzione. Le cose da OOP - unità per singolo interessato. Nel tuo caso è scala mixin con target specifici per scala roba.

Quindi ho delegate.xml che delega i progetti secondari alle attività di compilazione comuni. Ho dist, all, test e tutto ciò che vuoi per il progetto multimodule. L'ordine di costruzione viene valutato con la buildlist delle attività ant-edy.

Ci sono anche alcuni altri file - ma questi sono i file strategicamente basilari che mi hanno aiutato ad avere una build riutilizzabile e controllabile con questo progetto GRANDE e MOLTO conservatore. Quindi, se sei interessato ai dettagli, non essere timido e contattami. Sarò molto lieto di aiutarti, perché i documenti di edera sono davvero comici e incompleti.

MODIFICA: Informazioni sui libri: Ant in Action può aiutarti, ho preso diverse idee da questo libro e consiglio vivamente a tutti di leggere. Lì puoi trovare anche cose da edera. E sui documenti di edera - scusa, è tutto ciò che è disponibile. Ma quando ero nei guai con questa edera ingombrante + formica - ho trovato diversi articoli interessanti sui blog privati. Quindi ... questo potrebbe colmare il vuoto in qualche modo.