Alles, was Sie über Maven wissen wollten – „Java-Projekt von A bis Z“

Hallo zusammen, liebe Freunde. Ich möchte mich gleich entschuldigen: Ich erinnere mich, dass ich versprochen habe, einmal pro Woche einen Artikel zu schreiben. Hat nicht funktioniert. Ich bin einfach noch nicht dazu gekommen, mich hinzusetzen und richtig zu schreiben, aber ich möchte es nicht so oder so machen. Ich werde mich nicht über die Gründe beschweren, da ich es nicht brauche und Sie sicherlich kein Interesse haben. Das Projekt ist nicht tot, es befand sich im Stillstand :) Wir machen weiter! Und das heutige Material ist Maven gewidmet.

Reden wir über Maven

Zuerst müssen Sie es installieren. Da ich einen Mac habe, kann ich die Installation natürlich nur für einen Mac zeigen. Es ist einfach Pech. Ich habe es vor langer Zeit installiert, also musst du es selbst machen :)

Warum brauchen wir Maven?

Maven ist zusammen mit Gradle und Ant ein Projekterstellungstool. Nur weil ich es in JRTB (JavaRush Telegram Bot) verwenden werde, möchte ich Sie auf den neuesten Stand bringen. Heutzutage entsteht kein einziges Projekt ohne Montagesystem, denn es vereinfacht unser Leben um ein Vielfaches. Dies erlaubt:

• • Rufen Sie alle erforderlichen Bibliotheken auf (in Bezug auf Tools für den Zusammenbau – Abhängigkeiten (d. h. Abhängigkeiten));
• • Bestimmen Sie genau, wie und in was das Projekt zusammengestellt werden muss (z. B. wollen wir es in WAR, JAR oder ausführbarem JAR sammeln);
• • Legen Sie die Projektversion an einer Stelle fest, damit sie während der Montage angezeigt wird.
• • das Projekt und seinen Lebenszyklus beschreiben;
• • sogenannte Plugins hinzufügen (traditionelle Version des englischen Wortes Plugin);
• • Bibliotheken in einem gemeinsamen Repository veröffentlichen, damit andere Projekte sie als Abhängigkeiten abrufen können.

Im Allgemeinen macht er viele Dinge, und sie sind alle nützlich. Ich sage Folgendes: Für unerfahrene Ingenieure ist es nicht notwendig, alle Funktionen von Anfang bis Ende zu kennen. Hier ist es wie bei Git wichtig, die Grundlagen und allgemeinen Konzepte zu verstehen. Das werden wir tun. Für uns beginnt Maven mit einer XML-Datei im Stammverzeichnis unseres Projekts namens pom.xml . Wir werden alles in der Praxis umsetzen, also erstellen wir zunächst unser erstes Projekt in der JavaRush-Community. Um alles sinnvoll zu machen, werde ich eine Vorlage für das Repository verwenden , in der die grundlegenden Dinge , die ich einmal auf JR beschrieben habe, bereits konfiguriert sind . Gehen Sie zum Erstellen zum Repository mit der Vorlage und klicken Sie auf die Schaltfläche „Diese Vorlage verwenden “: Als Ergebnis haben wir das erste Repository in unserer Community :) Wir laden das Projekt lokal herunter. Gehen Sie dazu über die Idee zu Datei -> Neu -> Projekt aus der Versionskontrolle . Geben Sie im erscheinenden Fenster einen Link zum Projekt auf Github ein (das Ergebnis wird besser, wenn jeder das gleiche Projekt separat erstellt und alle Schritte mit mir durchgeht): Klicken Sie auf Klonen , und das Projekt wird geklont .

pom.xml ist der Kopf von allem

Alles, was Sie brauchen, ist in pom.xml. Alle Informationen über das Projekt, seinen Entwickler und auf welchem ​​Remote-Repository das Projekt gespeichert ist. Zu Beginn interessieren uns folgende Blöcke: <project/> – das ist der Hauptblock, der alle Informationen über das Projekt enthält. Alle anderen werden explizit oder transitiv darin sein. Im Eröffnungs-Tag steht etwa Folgendes:

<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">

Und obendrein ist die nächste Zeile auch in allen Pomniks geschrieben (der Slang stammt angeblich aus pom.xml :)).

<modelVersion>4.0.0</modelVersion>

Aber dann wird es interessanter: Wir werden beschreiben, wie wir das Projekt identifizieren, das unsere Gedenkstätte beschreibt. Am Beispiel meiner Bibliothek beschreibe ich sie, und dann fügen wir sie unserem Gedächtnis und dem neu erstellten Projekt hinzu:

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

<name>Image Comparison</name>

Die Hauptsache hier:

• • groupId ist die Kennung der Entwicklungsorganisation oder des einzelnen Ingenieurs. Dies ist normalerweise die Domäne in umgekehrter Reihenfolge. Als Beispiel wird hier der romankh3- Account auf Github beschrieben. Es ist sehr wichtig. Nehmen wir an, für das Spring-Ökosystem ist es com.springframework . Auf diese Weise können Sie das Originalprojekt von der Abzweigung einer anderen Person oder einfach durch die Übereinstimmung des Projektnamens unterscheiden.
• • artifaceId ist bereits der Name eines bestimmten Projekts, das in diesem Speicher beschrieben wird.
• • version – die Version dieses Projekts. Hier ist alles klar und deutlich: neue Funktionen hinzugefügt, alte behoben, umgestaltet oder andere Änderungen vorgenommen – die Version wurde erweitert.
• • Verpackung – hier beschreiben wir, wie Maven unser Projekt zusammenstellen soll. Entweder in Jar oder in War oder in einigen anderen .
• • Name – hier ist ein gefälligerer Name für das Projekt.

Es gibt noch einige Dinge, die überhaupt nicht ausgefüllt werden müssen – Maven funktioniert auch ohne sie – aber wenn Sie die Bibliothek für die öffentliche Nutzung veröffentlichen müssen, lohnt es sich auf jeden Fall, sie hinzuzufügen. Was sind diese Dinge?

• • Pfad zum Projekt-Repository, von wo es heruntergeladen werden kann

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

• • die Lizenz, unter der dieses Projekt vertrieben wird. Darüber hinaus kann es mehr als eine geben, daher müssen Sie es folgendermaßen einstellen:

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

• • Informationen über die Entwickler, die das Projekt erstellt haben/erstellen:

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

• • scm-Block, der beschreibt, wie auf das Projekt zugegriffen werden kann:

  <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>

Nachdem wir die allgemeinen Informationen beschrieben haben, können wir einen Block mit Abhängigkeiten hinzufügen:

<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>

Hier habe ich zum Testen zwei Bibliotheken hinzugefügt: Sie werden immer benötigt. Wie Sie vielleicht bereits bemerkt haben, haben Abhängigkeiten einen Scope – Umfang. In unserem Fall ist test angegeben , was bedeutet, dass wir diese Abhängigkeit im Hauptcode einfach nicht sehen werden. Damit alles schön aussieht, können Sie als Nächstes ein separates Tag verwenden, um die <properties/>- Versionen anzuzeigen :

<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>

Daher kann der Abhängigkeitsblock mithilfe des Konstrukts ${PROPERTY_NAME} aktualisiert werden :

<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>

Als nächstes kommt ein großer <build/>- Block , der einen wichtigen <plugins/>- Block enthält , mit dem Sie den Build-Prozess anpassen können. Sie können ein oder mehrere Plugins innerhalb des <plugins/>- Blocks hinzufügen , wie folgt:

<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>

Hier können Sie sehen, dass ich zwei Plugins hinzugefügt habe – maven-source-plugin und maven-javadoc-plugin . Jedes der Plugins verfügt über Einstellungen und Attribute (Parameter), die eingestellt werden können, wodurch die Plugins individuell angepasst werden können. Das wird für uns in Zukunft interessant sein. Erinnern wir uns zunächst einmal daran und machen wir weiter. Auf die gleiche Weise wie bei Abhängigkeiten werden wir die Plugin-Versionen in <properties/> ablegen . Darauf aufbauend können Sie folgenden Speicher erstellen:

<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>

Maven-Lebenszyklus

Maven hat so etwas wie einen Maven-Lebenszyklus. Es ist erwähnenswert, dass dies eine Reihe von Aufgaben ist, die ein Maven ausführen kann. Möglicherweise gibt es neben dem Maven-Lebenszyklus noch andere Aufgaben. Worum geht es? Есть набор команд, при помощи которых можно собирать проект ( билдить … опять, конечно, калька с английского, но без этого никуда), удалять билды, которые собрал Мавен, устанавливать в Maven local так, чтобы можно было локально подтягивать себе проект Wie зависимость, usw. Lassen Sie uns nun ausführlicher über alles sprechen. Bevor ich meine Meinung über diese Teams niederschrieb, beschloss ich, zu lesen, was sie zu diesem Thema im Internet schrieben ... und stellte fest, dass es sehr schwer zu beschreiben war. Für die Arbeit, für die Erstarbeit, benötigen wir mehrere Befehle . Beschreiben wir sie:

• • kompilieren – Kompilieren Sie das Projekt. Dies ist die erste Phase: Während dieser Phase können Sie sehen, ob im Projekt Kompilierungsfehler vorliegen. Manchmal gibt es bei der Arbeit in IDEA verschiedene Sprünge, weshalb Kompilierungsprobleme dort auftreten, wo sie nicht existieren sollten. Dieser Befehl wird also alle i-Punkte setzen.
• • test – führt alle Tests aus, die auf JUnit laufen und sich dort befinden, wo Maven sie erwartet ( src/test/java ist Ihr Kapitän).
• • Paket ist der nächste Befehl, der die beiden vorherigen enthält: Das heißt, der Kompilierungsbefehl wird zuerst darin gestartet, dann wird der Testbefehl an das kompilierte Projekt gesendet , und wenn hier alles in Ordnung ist, beginnt die Erstellung eines Archivs (das Archiv, das wir in <packaging/> auswählen))
• • install – wenn wir Maven auf einer Maschine installieren, verfügen wir über ein lokales Git-Repository, das die Bibliotheken speichert, die wir für Projekte herunterladen. Aber das Schöne an Maven ist, dass wir den Befehl install verwenden können, um unser Projekt zum lokalen Git-Repository hinzuzufügen und unser Projekt lokal als Abhängigkeit zu verwenden. Glauben Sie mir nicht? Probieren Sie es aus :) Auf diese Weise können Sie schnell erkennen, wie Ihr Projekt als Abhängigkeit von einem anderen aussehen wird.
• • Deploy ist die Krönung von allem, was vorher war. Ein Befehl, der die Möglichkeit bietet, ein Projekt nicht nur als Installation zu einem lokalen Repository hinzuzufügen, sondern auch zu einem Remote-Repository, von wo aus jeder mit Zugriff es als Abhängigkeit verwenden kann.
• • „Verify“ – ein Befehl, der alles überprüft und feststellt, ob das Projekt für die Bereitstellung bereit ist.
• • sauber – natürlich müssen die kompilierten Dateien und das Archiv irgendwo gespeichert werden. Maven hat dafür einen Zielordner . Dabei handelt es sich um Daten, die das Projekt nicht benötigt. Und bevor Sie das Projekt wieder zusammensetzen, wäre es gut, alles zu löschen, was vorher war. Dafür gibt es den Clean- Befehl .

Maven-Plugins

Ich wollte mehr über Plugins sprechen, aber der Artikel ist schon lang. Das wird deine Hausaufgabe sein. Verstehen Sie, was es ist und wie Sie es verwenden. Im weiteren Verlauf des Artikels werden wir uns mit Maven in der Praxis befassen.

Eine Liste aller Materialien der Serie finden Sie am Anfang dieses Artikels.