Apache Maven - Apache Maven

Apache Maven
Apache Maven logo.svg
Sviluppatore/i Apache Software Foundation
Versione iniziale 13 luglio 2004 ; 17 anni fa ( 2004-07-13 )
Rilascio stabile
3.8.3 / 27 settembre 2021 ; 14 giorni fa ( 2021-09-27 )
Repository Repository Maven
Scritto in Giava
Tipo Strumento di costruzione
Licenza Licenza Apache 2.0
Sito web Maven .apache .org

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

Il numero di artefatti nel repository centrale di Maven è cresciuto rapidamente

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

Una struttura di directory per un progetto Java generata automaticamente da Maven

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 packagecompilerà 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.xmlfile. 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 testcomando 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 installcrea 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:

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

link esterno