2009-02-06 4 views
11

Sto provando a rinnovare il nostro processo di compilazione, che è attualmente un gigantesco Ant build.xml che chiama in altri file ant form ed esegue diverse classi Java per eseguire una logica più complessa che sarebbe impossibile/terrificante tentare in Ant.Cosa si usa per un processo di compilazione complesso?

Sfondo:

  • esperienza in Java e Ant, alcune piattaforme
  • di Windows Groovy

Obiettivi:

  • corsa come una combinazione di linea di comando cron e quando un servlet è pubblicato su
  • come simplifi ndr il più possibile, meno lingue e rimbalzi tra i tecnici

Ho bisogno di un livello logico di livello superiore che un linguaggio come Java fornisce e Ant è piuttosto semplice e usiamo il filtro per sovrascrivere i file di proprietà predefiniti per diversi client. Principalmente mi chiedo se c'è qualcosa di diverso da Ant/Java che le persone usano.

+2

Basta correre, correre via urlando ..... – Skizz

risposta

8

Tranne la Formica lei ha citato e le Scarry effettuare/autotools, gli strumenti principali sono:

io uso SCons, perché è basato su Python, ben finanziato ed elegante. Jam sembra essere il più pragmatico. Non so molto di CMake. Maven potrebbe essere la scelta giusta per te dato che è Java centric e più alto di Ant.

più si possono trovare su Wikipedia: List of built tools

+0

Maven è sicuramente una buona scelta. –

+2

@Mark Davidson: Maven è solo una buona scelta finché non hai provato una build complessa per un po ', hai imparato a conoscere il lato oscuro di Maven e poi devi ricominciare con un altro strumento. Maven ti farà piangere, urlare e impazzire per qualcosa di non banale. –

+1

Gradle si presenta come un personaggio molto interessante. Mi piace il fatto che fornisca script insieme all'integrazione di maven/edera –

3

Mi piace usare Rake come si può ricorrere al potere dell'intera lingua Ruby e della libreria di framework quando necessario.

+0

e che dire corvo? :) – rkj

3

Io uso Ant, sfruttando il suo macro feature. Se imposti il ​​tuo progetto in un modo coerente, puoi eliminare molte duplicazioni scrivendo macro.

Ho creato uno Antlib contenente macro e attività personalizzate che riutilizza in più progetti.

In alternativa, alcune persone giurano su Maven. Altre persone giurano su Maven.

4

anche dare un'occhiata al

Mentre più general purpose costruire sistemi come SCons sono molto potenti, il supporto Java è in qualche modo limitato rispetto ai sistemi appositamente progettati per la realizzazione di progetti Java cts.

2

Io uso Maven, non solo per la build, uso anche il loro plugin di rilascio/dist.

In una coppia di comandi posso avere il codice che era in un controllo sorgente per creare, pacchettizzare e rilasciare.

Il plugin di rilascio gestisce l'aggiornamento dei numeri di versione, le maniglie dist come mettere tutto insieme e comprimerlo.

Ant sembra difficile rispetto a Maven. Certo, c'è una curva di apprendimento con Maven, ma leggere un pom.xml è molto più facile che leggere un build.xml.

Maven deve essere molto meno dettagliato.

1

Mi piace Ant ma solo se passi il tempo a scrivere i tuoi plugin Java per incapsulare azioni complesse. Non è difficile ma sfortunatamente la maggior parte delle persone prova a scrivere la loro logica in XML con la roba ant-contrib. Penso che questo sia un grosso errore.

Ho sentito cose buone sul rake e gli strumenti groovy (menzionato in un altro commento) ma non ho esperienza con loro.

Se si sta tentando di eseguire script in più passaggi in un ciclo di vita, potrebbe essere meglio utilizzare un server di build basato sull'automazione dei processi come AnthillPro (Cruise, BuildForge e Electric-Commander sono gli altri in questo spazio).

Un altro posto dove porre questo tipo di domande è lo CITCON mailing list. CITCON è una conferenza sull'integrazione e il test continui e la mailing list associata è diventata una grande comunità intorno a questi tipi di argomenti.

(io sono un organizzatore per CITCON ma un lavoro d'amore, non un creatore di profitto. In realtà non ha una mailing list veramente utile. Se fossi sfruttamento della prostituzione qualcosa per soldi sarebbe The CI Guys ;-).)

7

Se insegui Maven, avrai due problemi: una build complessa e l'apprendimento della "magia" di Maven. Maven peggiora il problema perché è ottuso e troppo complicato.

Ho ereditato un edificio Maven 1.x legacy in una grande azienda Fortune 500. Ho usato Maven 2.x per scelta su molti altri progetti negli ultimi anni. Ho valutato Maestro, nella speranza che potesse rendere Maven trattabile. La mia conclusione, come molti altri popoli "(controlla la rete), è che Maven è un grande passo nella direzione sbagliata. Non è sicuramente un miglioramento rispetto ad Ant.

Ho usato Ant per molti anni, compresa la scrittura di una grande libreria open-source di script di supporto Ant. Ho anche ampiamente utilizzato il suo cugino .NET nAnt. Tuttavia, Ant ha due problemi principali. Uno, XML non è semplicemente il posto giusto per svolgere compiti di costruzione. Due, Ant e XML non si adattano bene a build grandi e complessi.In effetti, ho scritto molto qui su SO riguardo le mie esperienze in quell'arena (e con Maven).

I leader del settore hanno concluso che una build è solo un'altra applicazione e che deve essere affrontata utilizzando strumenti di applicazione generali. Tuttavia, poiché implica funzionalità a livello di sistema e multipiattaforma, la maggior parte delle lingue/piattaforme di sviluppo non sono adattate correttamente (che include Java e quindi Ant e Maven). Ciò esclude anche .NET.

Ho passato due anni a cercare un'alternativa e l'ho trovato: Python. Ha la giusta combinazione di accesso a livello di sistema, portabilità multipiattaforma, semplicità, leggibilità, potenza, robustezza e maturità. SCons, buildbot, setuptools/easyinstall e Python base sono la mia attuale piattaforma di destinazione per il processo di compilazione. Quando necessario, l'integrazione con Ant, Maven e qualsiasi altro strumento di questo tipo è facile. Nel frattempo, posso usare questi strumenti per il nucleo di qualsiasi build su qualsiasi piattaforma con qualsiasi lingua di partenza. Niente più blocchi stradali, niente più folli complessità, niente più presunti scripting "dichiarativi", niente più black-box f @ * # ing "magic".

Se non è possibile passare a Python, quindi provare Ant + Ivy (su apache.org). Ti dà il bel repository di Maven senza la maggior parte dei mali di Maven. Questo è quello che sto facendo anche io, dove necessario e adatto.

I migliori auguri.

+0

Ho trovato la stessa cosa con Maven. Curva di apprendimento estremamente complicata, grande, molta MAGIA. Sono finito in Groovy ma principalmente per familiarità con Java e l'integrazione con ant. Non ho usato Python, ma ho sentito cose buone. – fooMonster

+1

La modifica dei linguaggi di programmazione a causa di un sistema di compilazione è ... discutibile. I sistemi di build Java garantiti fanno schifo, ma vale la pena notare che C/C++ è in realtà peggiore. Spero comunque che qualcuno uscirà con un sostituto Ant/Maven. – Gili

0

Utilizziamo luntbuild. È un'applicazione web molto facile da usare. Verificherà da CVS/SVN, incrementerà automaticamente il numero di versione/build, eseguirà le attività di compilazione negli script delle formiche e taggherà il tuo repository con la nuova versione. È possibile pianificare build automatiche, inviarle tramite posta elettronica o contattarti via chat, inoltre ha sicurezza e crea dipendenze.

Stiamo ancora utilizzando la versione 1.2.3, ma vedo che è fino a 1.6.0. Funziona e basta.

http://luntbuild.javaforge.com/

EDIT: Rileggendo la tua domanda Vedo ora che siete alla ricerca di qualcosa per sostituire Ant. Nel nostro caso, Ant non è davvero un problema. Abbiamo la configurazione dei progetti in Netbeans, che utilizza Ant per la creazione e dobbiamo solo implementare alcuni hook negli script esistenti forniti da Netbeans, operazione molto semplice da eseguire.

EDIT: Sembra che si possa chiamare Ant da Groovy. Sarebbe bello perché poi puoi riutilizzare tutte le attività che già esistono per Ant.

http://groovy.codehaus.org/Using+Ant+from+Groovy

0

utilizzare Rake ovunque posso. Dove hai bisogno di costruire codice java potresti usarlo con jruby, o guardare qualcosa come: buildr

1

Attaccare con Ant da quando stai costruendo Java. Ho mescolato Ant/SCons per alcuni lavori JNI, ma in generale starei con Ant soprattutto da quando hai una configurazione di build esistente in Ant. Portare a Maven sarà come spingere un piolo quadrato attraverso un muro senza buchi.

Abbraccia la tua logica Java personalizzata per qualsiasi e prendi in considerazione la scrittura di attività Ant adeguate anziché eseguire codice Java esterno. Ho risolto alcune parti molto complesse del nostro processo di costruzione semplicemente estendendo Ant per fare esattamente ciò di cui avevo bisogno, es. gestione delle risorse icona per un grande progetto gui o iniettato sovversione informazioni direttamente manifesta informazioni vaso (grazie svnkit)

0

Prova FinalBuilder

Esso fornisce un'interfaccia GUI per qualunque sia il vostro processo di compilazione può essere ed ha un'azione nativo per quasi tutto, oltre a uno studio d'azione in cui puoi creare il tuo.

Con un po 'di pianificazione può essere molto razionalizzato.

+0

Più i loro annunci pubblicitari includono Jon Skeet! Che cosa vuoi di più? –

1

Vorrei andare con Ant qualsiasi giorno della settimana.

Non è perfetto; L'XML è molto prolisso e l'implementazione di qualsiasi logica è quasi impossibile, ma anche l'ingegnere più giovane del team può almeno capire che cosa fa il file ant in un giorno.

La logica complessa può essere rifatta utilizzando java e integrata nella formica, se lo si desidera. Ant ti dà tutta la potenza di java :)

La risoluzione delle dipendenze è difficile, non importa quale sistema si utilizza. Con ant, le migliori soluzioni sembrano essere una directory lib in cui sono memorizzati tutti i tuoi jar o un server Web interno da cui le librerie vengono copiate in fase di compilazione.

Ho anche qualche esperienza con Maven 1 e Maven 2. Quell'esperienza mi ha lasciato la sensazione che Maven sia fantastico per progetti di hobby, ma può avere complicazioni per il software che è necessario mantenere nel tempo.

vedo due problemi importanti con Maven:

  • qualsiasi dipendenza si importano utilizzando Maven può cambiare nel tempo senza di voi saperlo, con conseguenti problemi strani.
  • È possibile importare le licenze dei non solo il software che si importare direttamente utilizzando Maven, ma anche le licenze utilizzate dalle librerie che sono indirettamente importati

Insomma, non mi piace il fatto che l'accumulo dipende dal tempo è iniziato. Questo può essere un vero problema quando si produce una versione di bugfix un anno dopo la versione di produzione.

Questi problemi possono naturalmente essere gestiti (magari utilizzando un proxy nexus) ma è necessario considerarli prima di ricostruire il sistema di generazione. Nella mia azienda abbiamo deciso di utilizzare Ant per tutti i nuovi progetti e provare a portare Maven 1 e 2 alle formiche ogni volta che si presenta l'occasione. È troppo difficile farlo funzionare.

Il mio consiglio, se tu e il tuo team sapete come affrontare la formica, provate a rifattorizzare il vostro file ant e non saltare su qualche altro strumento di costruzione. Ci vuole troppo tempo per farlo bene; tempo che potresti spendere facendo soldi e sopravvivere come azienda :)

+0

I problemi menzionati con Maven sono fuorvianti. Le dipendenze non cambiano nel tempo a meno che non si specifichi intenzionalmente intervalli. Le licenze non sono diverse con Maven che con qualsiasi altra cosa, ad eccezione forse del fatto che puoi vedere cosa stai usando con Maven. –

0

Devo aggiungere a questa soluzione che trovo che non posso vivere senza ... il suo nome è Hudson. Ci vogliono solo pochi secondi per la configurazione e di solito puoi farla franca con la maggior parte di ciò che i tuoi file ANT esistenti stanno già facendo.

Inoltre, Hudson fornisce un ottimo modo per creare "cron", eseguire test case e generare "artefatti" (ad esempio prodotti di sviluppo) in modo che chiunque possa scaricare.

È difficile catturare tutto ciò che può fare per voi ... quindi provatelo ... non sarete delusi.

0

Maven è davvero una buona scelta per fare grandi build ... nella maggior parte dei casi in cui non funziona è molto semplice. La gente fraintende i concetti di Maven. Se stai lavorando con il "modo esperto" ti ritroverai con moduli più piccoli che ti offrono un'architettura migliore nel tuo software. D'altra parte cose come Hudson ti aiuteranno a ridurre i tempi di costruzione usando Maven, perché Hudson supporta la costruzione di moduli modificati che non sono supportati da nessun altro strumento di costruzione.Il problema con Maven è di apprendere e comprendere i concetti di Maven, ad esempio la struttura di un progetto (cartelle ecc.) O solo un singolo artefatto, ecc. Il ciclo di sviluppo ti supporterà in diverse aree: compilazione, packaging, distribuzione e rilascio che non è supportato da altri strumenti (solo se lo si implementa a mano ... Ho scritto molti script di Ant grandi per raggiungerlo) ... Altri problemi come i cambiamenti nel tempo sono causati dall'ignorare le migliori pratiche e il puntamento dei pin versioni che vengono utilizzate.

-1

Io uso principalmente Ant, ma Maven è anche un buon strumento. Con la formica puoi fare tutto ciò che vuoi.

Nella nostra azienda, abbiamo creato un generatore di antuso generico che fa molte cose: costruisci, componi immagini, riduci, generi documentazione, file pack .. È open source e siamo aperti a miglioramenti. È possibile ottenere qui:

https://github.com/edertone/TurboBuilder