Tutto quello che avresti voluto sapere su Maven - "Progetto Java dalla A alla Z"

Ciao a tutti, cari amici. Vorrei scusarmi subito: ricordo che avevo promesso che avrei scritto un articolo una volta alla settimana. Non ha funzionato. Semplicemente non sono riuscito a sedermi e scrivere correttamente, ma non voglio farlo in questo o quello. Non mi lamenterò dei motivi, dato che non ne ho bisogno e di certo non ti interessa. Il progetto non è morto, era in stasi :) Continuiamo! E il materiale di oggi è dedicato a Maven.

Parliamo di Maven

Per prima cosa devi installarlo. Naturalmente, poiché ho un Mac, posso mostrare solo l'installazione per Mac. È solo sfortuna. L'ho installato molto tempo fa, quindi dovrai farlo da solo :)

Perché abbiamo bisogno di Maven?

Maven è uno strumento di creazione di progetti, insieme a Gradle e Ant. Solo perché lo userò in JRTB (JavaRush Telegram Bot), voglio aggiornarti. Al giorno d'oggi, non viene creato un solo progetto senza un sistema di assemblaggio, perché semplifica la nostra vita molte volte. Questo permette:

• • estrarre tutte le librerie necessarie (in termini di strumenti per l'assemblaggio - dipendenze (cioè dipendenza));
• • determinare esattamente come deve essere assemblato il progetto e in cosa (ad esempio, vogliamo raccoglierlo in WAR o JAR o eseguibile JAR);
• • posizionare la versione del progetto in un unico posto in modo che venga indicata durante il montaggio;
• • descrivere il progetto e il suo ciclo di vita;
• • aggiungere i cosiddetti plugin (versione tradizionale della parola inglese Plugin);
• • pubblicare le librerie in un repository condiviso in modo che altri progetti possano recuperarle come dipendenze.

In generale, fa molte cose e sono tutte utili. Dirò questo: per gli ingegneri alle prime armi non è necessario conoscere tutte le funzionalità dall'inizio alla fine. Qui, come con git, è importante comprendere le basi e i concetti generali. Questo è ciò che faremo. Per noi, Maven inizia con un file XML nella radice del nostro progetto chiamato pom.xml . Faremo tutto in pratica, quindi per prima cosa creeremo il nostro primo progetto nella comunità JavaRush. Per fare tutto con saggezza, utilizzerò un modello per il repository , dove sono già configurate le cose di base che ho descritto una volta su JR . Per creare, vai al repository con il modello e fai clic sul pulsante Usa questo modello : di conseguenza, abbiamo il primo repository nella nostra comunità :) Scarichiamo il progetto localmente. Per fare ciò, attraverso l'idea, vai su File -> Nuovo -> Progetto da Controllo versione . Nella finestra che appare, inserisci un collegamento al progetto su Github (il risultato sarà migliore se tutti creeranno lo stesso progetto separatamente e seguiranno tutti i passaggi con me): fai clic su Clone e il progetto verrà clonato .

pom.xml è il capo di tutto

Tutto ciò di cui hai bisogno è in pom.xml. Tutte le informazioni sul progetto, sul suo sviluppatore e su quale repository remoto è archiviato il progetto. All'inizio siamo interessati ai seguenti blocchi: <progetto/> - questo è il blocco principale, che contiene tutte le informazioni sul progetto. Tutti gli altri vi saranno esplicitamente o transitivamente. All'interno del tag di apertura c'è scritto qualcosa del genere:

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://maven.apache.org/POM/4.0.0"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                     http://maven.apache.org/xsd/maven-4.0.0.xsd">

E oltre a tutto il resto, anche la riga successiva è scritta in tutti i pomnik (lo slang presumibilmente deriva da pom.xml :)).

<modelVersion>4.0.0</modelVersion>

Ma poi la cosa diventa più interessante: descriveremo come identifichiamo il progetto che il nostro memoriale descrive. Usando come esempio la mia libreria, la descriverò, e poi la aggiungeremo alla nostra memoria, al progetto appena creato:

<groupId>com.github.romankh3</groupId>
<artifactId>image-comparison</artifactId>
<version>4.4.0-SNAPSHOT</version>
<packaging>jar</packaging>

<name>Image Comparison</name>

La cosa principale qui:

• • groupId è l'identificatore dell'organizzazione di sviluppo o del singolo ingegnere. Di solito questo è il dominio in ordine inverso. Ad esempio, l' account romankh3 su Github è descritto qui. È molto importante. Diciamo che per l'ecosistema Spring è com.springframework . In questo modo puoi distinguere il progetto originale dal fork di qualcun altro o semplicemente dalla coincidenza del nome del progetto.
• • artifaceId è già il nome di un progetto specifico descritto in questa memoria.
• • versione : la versione di questo progetto. Qui tutto è chiaro come il giorno: aggiunte nuove funzionalità, corrette quelle vecchie, refactoring o apportate altre modifiche - aumentata la versione.
• • packaging : qui descriviamo come Maven dovrebbe assemblare il nostro progetto. O in Jar, o in War, o in altri .
• • nome : ecco un nome più gradevole per il progetto.

Ci sono ancora alcune cose che non è necessario compilare - Maven funzionerà senza di esse - ma se devi pubblicare la libreria per uso pubblico, vale sicuramente la pena aggiungerle. Cosa sono queste cose?

• • percorso del repository del progetto, da dove può essere scaricato

  <url>https://romankh3.github.io/image-comparison/</url>

• • la licenza con la quale questo progetto è distribuito. Inoltre, potrebbe essercene più di uno, quindi è necessario impostarlo in questo modo:

  <licenses>
   <license>
     <name>The Apache Software License, Version 2.0</name>
     <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
   </license>
  </licenses>

• • informazioni sugli sviluppatori che hanno creato/stanno creando il progetto:

  <developers>
   <developer>
     <id>romankh3</id>
     <name>Roman Beskrovnyi</name>
     <email>roman.beskrovnyy@gmail.com</email>
   </developer>
  </developers>

• • blocco scm, che descrive la modalità di accesso al progetto:

  <scm>
  <connection>git@github.com:romankh3/image-comparison.git</connection>
  <developerConnection>git@github.com:romankh3/image-comparison.git</developerConnection>
   <url>https://github.com/romankh3/image-comparison</url>
  </scm>

Dopo aver descritto le informazioni generali, possiamo aggiungere un blocco con le dipendenze:

<dependencies>
   <dependency>
       <groupId>org.mockito</groupId>
       <artifactId>mockito-core</artifactId>
       <version>2.26.0</version>
       <scope>test</scope>
   </dependency>
   <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-api</artifactId>
       <version>5.5.2</version>
       <scope>test</scope>
   </dependency>
<dependency>
   	<groupId>com.github.romankh3</groupId>
   	<artifactId>image-comparison</artifactId>
   	<version>4.3.0</version>
<scope>test</scope>
</dependency>
</dependencies>

Qui ho aggiunto due librerie per i test: sono sempre necessarie. Come avrai già notato, le dipendenze hanno uno Scope - scope. Nel nostro caso , viene specificato test , il che significa che semplicemente non vedremo questa dipendenza nel codice principale. Successivamente, per rendere tutto bello, puoi utilizzare un tag separato per visualizzare le versioni <properties/> :

<properties>
   <mockito.version>2.26.0</mockito.version>
   <junit.version>5.5.2</junit.version>
   <image.comparison.version>4.3.0</image.comparison.version>
</properties>

Quindi il blocco delle dipendenze può essere aggiornato utilizzando il costrutto ${PROPERTY_NAME} :

<dependencies>
   <dependency>
       <groupId>org.mockito</groupId>
       <artifactId>mockito-core</artifactId>
       <version>${mockito.version}</version>
       <scope>test</scope>
   </dependency>
   <dependency>
       <groupId>org.junit.jupiter</groupId>
       <artifactId>junit-jupiter-api</artifactId>
       <version>${junit.version}</version>
       <scope>test</scope>
   </dependency>
   <dependency>
       <groupId>com.github.romankh3</groupId>
       <artifactId>image-comparison</artifactId>
       <version>${image.comparison.version}</version>
       <scope>test</scope>
   </dependency>
</dependencies>

Poi c'è un grande blocco <build/> , che contiene un importante blocco <plugins/> , con il quale è possibile personalizzare il processo di compilazione. Puoi aggiungere uno o più plugin all'interno del blocco <plugins/> , in questo modo:

<build>
   <plugins>
       <plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-source-plugin</artifactId>
           <version>3.2.0</version>
           <executions>
               <execution>
                   <id>attach-sources</id>
                   <goals>
                       <goal>jar</goal>
                   </goals>
               </execution>
           </executions>
       </plugin>
   </plugins>
</build>

Qui puoi vedere che ho aggiunto due plugin: maven-source-plugin e maven-javadoc-plugin . Ciascuno dei plugin ha impostazioni, attributi (parametri) che possono essere impostati, personalizzando così i plugin. Questo sarà interessante per noi in futuro. Per ora ricordiamoci e andiamo avanti. Allo stesso modo delle dipendenze, inseriremo le versioni del plugin in <properties/> . Sulla base di ciò, puoi creare la seguente memoria:

<project xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="http://maven.apache.org/POM/4.0.0"
        xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                     http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>

   <groupId>com.github.javarushcommunity</groupId>
   <artifactId>maven-demo</artifactId>
   <version>1.0-SNAPSHOT</version>
   <packaging>jar</packaging>

   <name>Maven Demo Project</name>

   <url>https://github.com/javarushcommunity/maven-demo/</url>

   <properties>
       <mockito.version>2.26.0</mockito.version>
       <junit.version>5.5.2</junit.version>
       <maven.compiler.source>1.8</maven.compiler.source>
       <maven.compiler.target>1.8</maven.compiler.target>
       <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
       <source.plugin.version>3.2.0</source.plugin.version>
   </properties>

   <dependencies>
       <dependency>
           <groupId>org.mockito</groupId>
           <artifactId>mockito-core</artifactId>
           <version>${mockito.version}</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>org.junit.jupiter</groupId>
           <artifactId>junit-jupiter-api</artifactId>
           <version>${junit.version}</version>
           <scope>test</scope>
       </dependency>
   </dependencies>

   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-source-plugin</artifactId>
               <version>${source.plugin.version}</version>
               <executions>
                   <execution>
                       <id>attach-sources</id>
                       <goals>
                           <goal>jar</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-javadoc-plugin</artifactId>
               <version>${javadoc.plugin.version}</version>
               <executions>
                   <execution>
                       <id>attach-javadocs</id>
                       <goals>
                           <goal>jar</goal>
                       </goals>
                   </execution>
               </executions>
           </plugin>
       </plugins>
   </build>
</project>

Ciclo di vita di Maven

Maven ha qualcosa come il ciclo di vita di Maven. Vale la pena dire che questo è un insieme di compiti che un esperto può eseguire. Potrebbero esserci altre attività oltre al ciclo di vita di Maven. Di cosa si tratta? C'è una serie di comandi con cui puoi assemblare un progetto ( build ... di nuovo, ovviamente, un foglio di lucido dall'inglese, ma senza questo non c'è da nessuna parte), eliminare le build raccolte da Maven, installarlo in Maven local in modo da poter richiamare localmente il progetto come dipendenza e così via. Ora parliamo di tutto in modo più dettagliato. Prima di scrivere la mia opinione su queste squadre, ho deciso di leggere cosa scrivevano su Internet sull'argomento... e ho capito che era molto difficile da descrivere. Per il lavoro, per il lavoro iniziale, abbiamo bisogno di diversi comandi . Descriviamoli:

• • compila : compila il progetto. Questa è la prima fase: durante essa puoi vedere se ci sono errori di compilazione nel progetto. A volte ci sono diversi passi avanti nel lavorare in IDEA, motivo per cui compaiono problemi di compilazione dove non dovrebbero esistere. Quindi questo comando punterà tutte le i.
• • test - esegue tutti i test eseguiti su JUnit e si trovano dove Maven li aspetta ( src/test/java è il tuo capitano).
• • package è il comando successivo, che comprende i due precedenti: cioè al suo interno si lancia prima il comando compile , poi si invia il comando test al progetto compilato , e se qui è tutto ok si avvia la creazione di un archivio (l'archivio che selezioniamo in < packaging/>))
• • installazione : quando installiamo Maven su una macchina, abbiamo un repository Git locale che memorizza le librerie che scarichiamo per i progetti. Ma la bellezza di Maven è che possiamo usare il comando install per aggiungere il nostro progetto al repository Git locale e utilizzare il nostro progetto localmente come dipendenza. Non mi credi? Provalo :) In questo modo puoi vedere rapidamente come il tuo progetto apparirà come una dipendenza da un altro.
• • schierare è il coronamento di tutto ciò che è venuto prima. Un comando che dà la possibilità di aggiungere un progetto non solo a un repository locale come installazione, ma anche a uno remoto, da dove chiunque abbia accesso può utilizzarlo come dipendenza.
• • verificare - un comando che controllerà tutto e dirà se il progetto è pronto per la distribuzione.
• • pulito : ovviamente i file compilati e l'archivio devono essere archiviati da qualche parte. Maven ha una cartella di destinazione per questo file . Si tratta di dati di cui il progetto non ha bisogno. E prima di rimontare il progetto sarebbe bene cancellare tutto quello che è venuto prima. Questo è lo scopo del comando clean .

Plugin Maven

Avrei voluto parlare più approfonditamente dei plugin, ma l'articolo è già lungo. Questo sarà il tuo compito. Capire cos'è e come usarlo. Nel seguito dell'articolo ci occuperemo di Maven nella pratica.

Un elenco di tutti i materiali della serie si trova all'inizio di questo articolo.