Apache Maven - Apache Maven
Sviluppatore/i | Apache Software Foundation |
---|---|
Versione iniziale | 13 luglio 2004 |
Rilascio stabile | 3.8.3 / 27 settembre 2021
|
Repository | Repository Maven |
Scritto in | Giava |
Tipo | Strumento di costruzione |
Licenza | Licenza Apache 2.0 |
Sito web | Maven |
Maven è uno strumento di automazione della build utilizzato principalmente per i progetti Java . Maven può essere utilizzato anche per creare e gestire progetti scritti in C# , Ruby , Scala e altri linguaggi. Il progetto Maven è ospitato dalla Apache Software Foundation , dove in precedenza faceva parte del progetto Jakarta .
Maven affronta due aspetti della creazione di software: come viene costruito il software e le sue dipendenze. A differenza degli strumenti precedenti come Apache Ant , utilizza le convenzioni per la procedura di compilazione. È necessario specificare solo le eccezioni. Un file XML descrive il progetto software in fase di compilazione, le sue dipendenze da altri moduli e componenti esterni, l'ordine di compilazione, le directory e i plug-in richiesti . Viene fornito con obiettivi predefiniti per l'esecuzione di determinate attività ben definite come la compilazione del codice e la sua confezione. Maven scarica dinamicamente le librerie Java e i plug-in Maven da uno o più repository come Maven 2 Central Repository e li memorizza in una cache locale. Questa cache locale di artefatti scaricati può anche essere aggiornata con artefatti creati da progetti locali. Anche i repository pubblici possono essere aggiornati.
Maven è costruito utilizzando un'architettura basata su plug-in che gli consente di utilizzare qualsiasi applicazione controllabile tramite input standard. Viene mantenuto un plug-in nativo C / C++ per Maven 2.
Le tecnologie alternative come Gradle e sbt come strumenti di compilazione non si basano su XML , ma mantengono i concetti chiave introdotti da Maven. Con Apache Ivy è stato sviluppato anche un gestore delle dipendenze dedicato che supporta anche i repository Maven.
Apache Maven supporta le build riproducibili .
Storia
Maven, creato da Jason van Zyl, è iniziato come sotto-progetto di Apache Turbine nel 2002. Nel 2003 è stato votato e accettato come progetto Apache Software Foundation di alto livello . Nel luglio 2004, il rilascio di Maven è stata la prima pietra miliare fondamentale, v1.0. Maven 2 è stato dichiarato v2.0 nell'ottobre 2005 dopo circa sei mesi di cicli beta. Maven 3.0 è stato rilasciato nell'ottobre 2010 essendo per lo più retrocompatibile con Maven 2.
Le informazioni su Maven 3.0 hanno iniziato a diffondersi nel 2008. Dopo otto versioni alfa, la prima versione beta di Maven 3.0 è stata rilasciata nell'aprile 2010. Maven 3.0 ha rielaborato l'infrastruttura di base di Project Builder con il risultato che la rappresentazione basata su file del POM è stata disaccoppiata dal suo in- rappresentazione di oggetti di memoria. Ciò ha ampliato la possibilità per i componenti aggiuntivi di Maven 3.0 di sfruttare i file di definizione del progetto non basati su XML. I linguaggi suggeriti includono Ruby (già in prototipo privato di Jason van Zyl), YAML e Groovy .
È stata prestata particolare attenzione a garantire la compatibilità con le versioni precedenti di Maven 3 e Maven 2. Per la maggior parte dei progetti, l'aggiornamento a Maven 3 non richiederà alcuna modifica della struttura del progetto. La prima beta di Maven 3 ha visto l'introduzione di una funzionalità di build parallela che sfrutta un numero configurabile di core su una macchina multi-core ed è particolarmente adatta per grandi progetti multi-modulo.
Sintassi
I progetti Maven sono configurati utilizzando un Project Object Model (POM) , che è memorizzato in un pom.xml
-file. Un file di esempio assomiglia a:
<project>
<!-- model version is always 4.0.0 for Maven 2.x POMs -->
<modelVersion>4.0.0</modelVersion>
<!-- project coordinates, i.e. a group of values which uniquely identify this project -->
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0</version>
<!-- library dependencies -->
<dependencies>
<dependency>
<!-- coordinates of the required library -->
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<!-- this dependency is only used for running and compiling tests -->
<scope>test</scope>
</dependency>
</dependencies>
</project>
Questo POM definisce solo un identificatore univoco per il progetto ( coordinate ) e la sua dipendenza dal framework JUnit . Tuttavia, questo è già sufficiente per creare il progetto ed eseguire gli unit test associati al progetto. Maven realizza ciò abbracciando l'idea di Convention over Configuration , ovvero Maven fornisce valori predefiniti per la configurazione del progetto.
La struttura di directory di un normale progetto Maven idiomatico ha le seguenti voci di directory:
Nome della directory | Scopo |
---|---|
progetto casa | Contiene il pom.xml e tutte le sottodirectory. |
src/main/java | Contiene il codice sorgente Java disponibile per il progetto. |
src/main/resources | Contiene le risorse consegnabili per il progetto, come i file delle proprietà. |
src/test/java | Contiene il codice sorgente Java di test (ad esempio, casi di test JUnit o TestNG) per il progetto. |
src/test/risorse | Contiene le risorse necessarie per il test. |
Il comando mvn package
compilerà tutti i file Java, eseguirà eventuali test e impacchetta il codice e le risorse consegnabili target/my-app-1.0.jar
(supponendo che artifactId sia my-app e la versione sia 1.0).
Utilizzando Maven, l'utente fornisce solo la configurazione per il progetto, mentre i plug-in configurabili svolgono il lavoro effettivo di compilazione del progetto, pulizia delle directory di destinazione, esecuzione di unit test, generazione di documentazione API e così via. In generale, gli utenti non dovrebbero scrivere i plugin da soli. Contrasta questo con Ant e fai , in cui si scrivono procedure imperative per svolgere i suddetti compiti.
Design
Modello oggetto progetto
Un Project Object Model (POM) fornisce tutta la configurazione per un singolo progetto. La configurazione generale copre il nome del progetto, il suo proprietario e le sue dipendenze da altri progetti. Si possono anche configurare singole fasi del processo di compilazione, che vengono implementate come plugin . Ad esempio, è possibile configurare il plug-in del compilatore per utilizzare Java versione 1.5 per la compilazione o specificare il confezionamento del progetto anche se alcuni test unitari falliscono.
I progetti più grandi dovrebbero essere suddivisi in diversi moduli, o sottoprogetti, ciascuno con il proprio POM. Si può quindi scrivere un POM di root attraverso il quale compilare tutti i moduli con un unico comando. I POM possono anche ereditare la configurazione da altri POM. Tutti i POM ereditano dal Super POM per impostazione predefinita. Il Super POM fornisce la configurazione predefinita, come directory di origine predefinite, plug-in predefiniti e così via.
Plug-in
La maggior parte delle funzionalità di Maven è nei plug-in . Un plugin fornisce una serie di obiettivi che possono essere eseguiti utilizzando il comando mvn [plugin-name]:[goal-name]
. Ad esempio, un progetto Java può essere compilato con l'obiettivo di compilazione del plug-in del compilatore eseguendo mvn compiler:compile
.
Esistono plug-in Maven per la creazione, il test, la gestione del controllo del codice sorgente, l'esecuzione di un server Web, la generazione di file di progetto Eclipse e molto altro. I plugin vengono introdotti e configurati in una sezione <plugins> di un pom.xml
file. Alcuni plugin di base sono inclusi in ogni progetto per impostazione predefinita e hanno impostazioni predefinite ragionevoli.
Tuttavia, sarebbe ingombrante se la sequenza archetipica di creazione, test e confezionamento di un progetto software richiedesse l'esecuzione manuale di ciascun rispettivo obiettivo:
mvn compiler:compile
mvn surefire:test
mvn jar:jar
Il concetto di ciclo di vita di Maven gestisce questo problema.
I plugin sono il modo principale per estendere Maven. È possibile sviluppare un plug-in Maven estendendo la classe org.apache.maven.plugin.AbstractMojo. Il codice di esempio e la spiegazione per un plug-in Maven per creare una macchina virtuale basata su cloud che esegue un server applicazioni sono forniti nell'articolo Automatizzare lo sviluppo e la gestione delle macchine virtuali cloud .
Costruisci cicli di vita
Il ciclo di vita della build è un elenco di fasi denominate che possono essere utilizzate per dare ordine all'esecuzione degli obiettivi. Uno dei cicli di vita standard di Maven è il ciclo di vita predefinito , che include le seguenti fasi, in questo ordine:
- convalidare
- generare-sorgenti
- fonti-processo
- generare-risorse
- risorse-processo
- compilare
- fonti-di-prova-processo
- processo-risorse-test
- compilazione di prova
- test
- pacchetto
- installare
- distribuire
Gli obiettivi forniti dai plugin possono essere associati a diverse fasi del ciclo di vita. Ad esempio, per impostazione predefinita, l'obiettivo "compiler:compile" è associato alla fase "compila", mentre l'obiettivo "surefire:test" è associato alla fase "test". Quando il mvn test
comando viene eseguito, Maven esegue tutti gli obiettivi associati a ciascuna delle fasi fino alla fase di "test" inclusa. In tal caso, Maven esegue l'obiettivo "resources:resources" associato alla fase "process-resources", quindi "compiler:compile" e così via fino a quando non esegue finalmente l'obiettivo "surefire:test".
Maven ha anche fasi standard per la pulizia del progetto e per la generazione di un sito di progetto. Se la pulizia fosse parte del ciclo di vita predefinito, il progetto verrebbe pulito ogni volta che viene creato. Questo è chiaramente indesiderabile, quindi la pulizia ha un proprio ciclo di vita.
I cicli di vita standard consentono agli utenti nuovi a un progetto la capacità di creare, testare e installare con precisione ogni progetto Maven emettendo il singolo comando mvn install
. Per impostazione predefinita, Maven impacchetta il file POM nei file JAR e WAR generati. Strumenti come diet4j possono utilizzare queste informazioni per risolvere ed eseguire in modo ricorsivo i moduli Maven in fase di esecuzione senza richiedere un jar "uber" che contenga tutto il codice del progetto.
dipendenze
Una caratteristica centrale di Maven è la gestione delle dipendenze . Il meccanismo di gestione delle dipendenze di Maven è organizzato attorno a un sistema di coordinate che identifica i singoli artefatti come librerie o moduli software. L'esempio POM sopra fa riferimento alle coordinate JUnit come dipendenza diretta del progetto. Un progetto che necessita, ad esempio, della libreria Hibernate deve semplicemente dichiarare le coordinate del progetto di Hibernate nel suo POM. Maven scaricherà automaticamente la dipendenza e le dipendenze di cui Hibernate stesso ha bisogno (chiamate dipendenze transitive ) e le memorizzerà nel repository locale dell'utente. Maven 2 Central Repository viene utilizzato per impostazione predefinita per cercare le librerie, ma è possibile configurare i repository da utilizzare (ad esempio, repository aziendali-privati) all'interno del POM.
La differenza fondamentale tra Maven e Ant è che il design di Maven considera tutti i progetti come aventi una certa struttura e un insieme di flussi di lavoro di attività supportati (ad esempio, ottenere risorse dal controllo del codice sorgente, compilare il progetto, test di unità, ecc.). Sebbene la maggior parte dei progetti software in effetti supporti queste operazioni e abbiano effettivamente una struttura ben definita, Maven richiede che questa struttura e i dettagli di implementazione dell'operazione siano definiti nel file POM. Pertanto, Maven si basa su una convenzione su come definire i progetti e sull'elenco dei flussi di lavoro generalmente supportati in tutti i progetti.
Esistono motori di ricerca come The Central Repository Search Engine, che possono essere utilizzati per trovare le coordinate per diverse librerie e framework open source.
I progetti sviluppati su una singola macchina possono dipendere l'uno dall'altro tramite il repository locale. Il repository locale è una semplice struttura di cartelle che funge sia da cache per le dipendenze scaricate sia da luogo di archiviazione centralizzato per gli artefatti creati localmente. Il comando Maven mvn install
crea un progetto e inserisce i suoi binari nel repository locale. Quindi, altri progetti possono utilizzare questo progetto specificando le sue coordinate nei loro POM.
Interoperabilità
Esistono componenti aggiuntivi per diversi ambienti di sviluppo integrato (IDE) popolari destinati al linguaggio di programmazione Java per fornire l'integrazione di Maven con il meccanismo di compilazione dell'IDE e gli strumenti di modifica dei sorgenti, consentendo a Maven di compilare progetti dall'interno dell'IDE e anche di impostare il percorso di classe per completamento del codice, evidenziazione degli errori del compilatore, ecc.
Esempi di IDE popolari che supportano lo sviluppo con Maven includono:
- Eclisse
- NetBeans
- IntelliJ IDEA
- JBuilder
- JDeveloper (versione 11.1.2)
- MyEclipse
- Codice di Visual Studio
Questi componenti aggiuntivi forniscono anche la possibilità di modificare il POM o utilizzare il POM per determinare l'insieme completo di dipendenze di un progetto direttamente all'interno dell'IDE.
Alcune funzionalità integrate degli IDE vengono perse quando l'IDE non esegue più la compilazione. Ad esempio, il JDT di Eclipse ha la capacità di ricompilare un singolo file sorgente Java dopo che è stato modificato. Molti IDE funzionano con un set piatto di progetti invece della gerarchia di cartelle preferita da Maven. Ciò complica l'uso dei sistemi SCM negli IDE quando si utilizza Maven.
Guarda anche
Riferimenti
Ulteriori letture
- O'Brien, Tim; et al. "Maven: il riferimento completo" . Sonatype.com . Sonatipo . Estratto il 15 marzo 2013 .
- Maven: la guida definitiva . Sonatype Company. O'Reilly Media, Inc. 2009. p. 470. ISBN 9780596551780. Estratto il 17/04/2013 .CS1 maint: altri ( link )
- Van Zyl, Jason (2008-10-01), Maven: Definitive Guide (prima ed.), O'Reilly Media , pp. 468 , ISBN 978-0-596-51733-5
- "Esecuzione di test JUnit da Maven2". JUnit in azione (2a ed.). Pubblicazioni Manning . 2011. pp. 152-168. ISBN 978-1-935182-02-3.
- Personalizzazione della build di Maven . pacchetto 2013. pp. 1-250. ISBN 9781783987221.
- Padroneggiare Apache Maven 3 . pacchetto 2014. pag. 298. ISBN 9781783983865.