Wszystko, co chciałeś wiedzieć o Maven - „Projekt Java od A do Z”

Witam wszystkich, drodzy przyjaciele. Od razu chcę przeprosić: pamiętam, że obiecałam, że raz w tygodniu będę pisać artykuł. Nie wypracował. Po prostu nie udało mi się usiąść i poprawnie pisać, ale nie chcę tego robić w ten czy inny sposób. Nie będę marudził o powodach, bo mi to nie jest potrzebne, a na pewno nie jesteś zainteresowany. Projekt nie umarł, był w zastoju :) Działamy dalej! A dzisiejszy materiał poświęcony jest Mavenowi.

Porozmawiajmy o Mavenie

Najpierw musisz go zainstalować. Oczywiście, ponieważ mam komputer Mac, mogę pokazać instalację tylko na komputerze Mac. To po prostu pech. Zainstalowałem to dawno temu, więc musisz to zrobić sam :)

Dlaczego potrzebujemy Mavena?

Maven to narzędzie do tworzenia projektów, podobnie jak Gradle i Ant. Tylko dlatego, że będę go używać w JRTB (JavaRush Telegram Bot), chcę przedstawić Ci aktualne informacje. W dzisiejszych czasach żaden projekt nie powstaje bez systemu montażu, gdyż wielokrotnie ułatwia on nam życie. To pozwala:

• • pobierz wszystkie niezbędne biblioteki (w zakresie narzędzi do montażu - zależności (czyli zależność));
• • określić dokładnie jak projekt ma być złożony i w co (np. czy chcemy go zebrać w WAR czy JAR czy wykonywalny JAR);
• • ustawić wersję projektu w jednym miejscu tak, aby była wskazywana podczas montażu;
• • opisać projekt i jego cykl życia;
• • dodać tzw. wtyczki (tradycyjna wersja angielskiego słowa Plugin);
• • publikować biblioteki we współdzielonym repozytorium, aby inne projekty mogły je pobierać jako zależności.

Ogólnie rzecz biorąc, robi wiele rzeczy i wszystkie są przydatne. Powiem tak: dla początkujących inżynierów nie jest konieczne poznanie wszystkich funkcji od deski do deski. Tutaj, podobnie jak w przypadku gita, ważne jest zrozumienie podstaw i ogólnych koncepcji. To właśnie zrobimy. W naszym przypadku Maven zaczyna od pliku XML w katalogu głównym naszego projektu o nazwie pom.xml . Wszystko zrobimy w praktyce, więc najpierw stworzymy nasz pierwszy projekt w społeczności JavaRush. Aby wszystko mądrze zrobić posłużę się szablonem dla repozytorium , gdzie są już skonfigurowane podstawowe rzeczy , które opisałem kiedyś na JR . Aby utworzyć, przejdź do repozytorium z szablonem i kliknij przycisk Użyj tego szablonu : Dzięki temu mamy pierwsze repozytorium w naszej społeczności :) Pobieramy projekt lokalnie. Aby to zrobić, poprzez pomysł, przejdź do Plik -> Nowy -> Projekt z Kontroli wersji . W oknie, które się pojawi, wpisz link do projektu na Githubie (wynik będzie lepszy, jeśli każdy stworzy ten sam projekt osobno i przejdzie ze mną wszystkie kroki): Kliknij Klonuj , a projekt zostanie sklonowany .

pom.xml jest głową wszystkiego

Wszystko, czego potrzebujesz, znajduje się w pliku pom.xml. Wszystkie informacje o projekcie, jego deweloperze i zdalnym repozytorium, w którym projekt jest przechowywany. Na początek interesują nas następujące bloki: <projekt/> - jest to główny blok, w którym znajdują się wszystkie informacje o projekcie. Wszystkie inne będą w nim jawne lub przechodnie. Wewnątrz tagu otwierającego jest napisane coś takiego:

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

A na dodatek we wszystkich pomnikach zapisana jest następna linijka (slang podobno pochodzi z pom.xml :)).

<modelVersion>4.0.0</modelVersion>

Ale potem robi się ciekawiej: opiszemy, jak identyfikujemy projekt, który opisuje nasz pomnik. Na przykładzie mojej biblioteki opiszę ją, a następnie dodamy ją do naszej pamięci, do nowo powstałego projektu:

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

<name>Image Comparison</name>

Najważniejsze tutaj:

• • groupId to identyfikator organizacji rozwojowej lub indywidualnego inżyniera. Zwykle jest to domena w odwrotnej kolejności. Jako przykład opisano tutaj konto romankh3 na Githubie. To jest bardzo ważne. Załóżmy, że w przypadku ekosystemu Spring jest to com.springframework . W ten sposób można odróżnić oryginalny projekt od cudzego forka lub po prostu zbieżność nazwy projektu.
• • artifaceId jest już nazwą konkretnego projektu opisanego w tej pamięci.
• • wersja — wersja tego projektu. Wszystko tutaj jest jasne jak słońce: dodano nowe funkcjonalności, poprawiono stare, dokonano refaktoryzacji lub dokonano innych zmian - zwiększono wersję.
• • opakowanie – tutaj opisujemy jak Maven powinien złożyć nasz projekt. Albo w Słoju, albo w Wojnie, albo w jakichś innych .
• • nazwa – tutaj jest bardziej przyjemna nazwa projektu.

Są jeszcze pewne rzeczy, których nie trzeba wypełniać – Maven obejdzie się bez nich – ale jeśli zachodzi potrzeba opublikowania biblioteki do użytku publicznego, na pewno warto je dodać. Co to za rzeczy?

• • ścieżka do repozytorium projektu, skąd można go pobrać

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

• • licencja, na której rozpowszechniany jest ten projekt. Co więcej, może być ich więcej niż jeden i dlatego musisz ustawić to w ten sposób:

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

• • informacje o programistach, którzy stworzyli/tworzą projekt:

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

• • blok scm, który opisuje sposób dostępu do projektu:

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

Po opisaniu informacji ogólnych możemy dodać blok z zależnościami:

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

Tutaj dodałem dwie biblioteki do testów: są zawsze potrzebne. Jak być może już zauważyłeś, zależności mają zakres. W naszym przypadku podany jest test , co oznacza, że ​​po prostu nie zobaczymy tej zależności w głównym kodzie. Następnie, aby wszystko wyglądało pięknie, możesz użyć osobnego tagu, aby wyświetlić wersje <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>

Zatem blok zależności można zaktualizować za pomocą konstrukcji ${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>

Następny jest duży blok <build/> , który zawiera ważny blok <plugins/> , za pomocą którego możesz dostosować proces kompilacji. Możesz dodać jedną lub więcej wtyczek wewnątrz bloku <plugins/> , w ten sposób:

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

Tutaj możesz zobaczyć, że dodałem dwie wtyczki - maven-source-plugin i maven-javadoc-plugin . Każda z wtyczek posiada ustawienia, atrybuty (parametry), które można ustawić, dostosowując w ten sposób wtyczki. Będzie to dla nas interesujące w przyszłości. Na razie pamiętajmy i idźmy dalej. Podobnie jak w przypadku zależności, wersje pluginów umieścimy w <properties/> . Na tej podstawie możesz utworzyć następującą pamięć:

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

Cykl życia Mavena

Maven ma coś takiego jak cykl życia Mavena. Warto powiedzieć, że jest to zestaw zadań, które może wykonać maven. Oprócz cyklu życia Mavena mogą istnieć inne zadania. O czym to jest? Istnieje zestaw poleceń, za pomocą których można zmontować projekt ( zbuduj … znowu oczywiście kalka z języka angielskiego, ale bez tego nie ma gdzie), usuń kompilacje, które zebrał Maven, zainstaluj w lokalnym Mavenie, abyś mógł lokalnie podciągnij projekt jako zależność i tak dalej. Porozmawiajmy teraz o wszystkim bardziej szczegółowo. Zanim napisałem swoją opinię o tych zespołach, postanowiłem przeczytać, co piszą w Internecie na ten temat… i zdałem sobie sprawę, że bardzo trudno to opisać. Do pracy, do pracy początkowej, potrzebujemy kilku poleceń . Opiszmy je:

• • skompiluj — skompiluj projekt. To pierwszy etap: w jego trakcie można sprawdzić, czy w projekcie nie występują błędy kompilacji. Czasami w pracy w IDEA zdarzają się różne przeskoki, dlatego problemy z kompilacją pojawiają się tam, gdzie nie powinny. Zatem to polecenie kropkuje wszystkie „i”.
• • test – uruchamia wszystkie testy działające na JUnit i zlokalizowane tam, gdzie oczekuje ich Maven ( twoim kapitanem jest src/test/Java ).
• • pakiet to kolejne polecenie, które zawiera dwa poprzednie: czyli najpierw w nim uruchamiane jest polecenie kompilacji , następnie do skompilowanego projektu wysyłane jest polecenie test i jeśli tutaj wszystko jest w porządku, rozpoczyna się tworzenie archiwum (archiwum, które wybieramy w <package/>))
• • zainstaluj – gdy instalujemy Mavena na komputerze, mamy lokalne repozytorium Git, w którym przechowywane są biblioteki, które pobieramy do projektów. Ale piękno Mavena polega na tym, że możemy użyć polecenia install , aby dodać nasz projekt do lokalnego repozytorium Git i używać naszego projektu lokalnie jako zależności. Nie wierzysz mi? Wypróbuj :) W ten sposób możesz szybko zobaczyć, jak Twój projekt będzie wyglądał w zależności od innego.
• • wdrożenie jest ukoronowaniem wszystkiego, co było wcześniej. Polecenie dające możliwość dodania projektu nie tylko do lokalnego repozytorium w ramach instalacji, ale także do zdalnego, skąd każdy mający dostęp może go używać jako zależności.
• • zweryfikować - polecenie, które sprawdzi wszystko i powie, czy projekt jest gotowy do wdrożenia.
• • czysty – oczywiście skompilowane pliki i archiwum muszą być gdzieś przechowywane. Maven ma do tego folder docelowy . Są to dane, których projekt nie potrzebuje. A przed ponownym złożeniem projektu dobrze byłoby usunąć wszystko, co było wcześniej. Do tego właśnie służy polecenie clean .

Wtyczki Mavena

Chciałem porozmawiać więcej o wtyczkach, ale artykuł jest już długi. To będzie twoja praca domowa. Dowiedz się, co to jest i jak z niego korzystać. W dalszej części artykułu zajmiemy się Mavenem w praktyce.

Lista wszystkich materiałów wchodzących w skład serii znajduje się na początku artykułu.