Tudo o que você queria saber sobre Maven - "Projeto Java de A a Z"

Olá a todos, queridos amigos. Gostaria de me desculpar desde já: lembro que prometi que escreveria um artigo uma vez por semana. Não funcionou. Só não consegui sentar e escrever direito, mas não quero fazer isso ou aquilo. Não vou reclamar dos motivos, já que não preciso disso e você certamente não está interessado. O projeto não morreu, estava em êxtase :) Continuamos! E o material de hoje é dedicado ao Maven.

Vamos falar sobre Maven

Primeiro você precisa instalá-lo. Claro, como tenho um Mac, só posso mostrar a instalação para Mac. É apenas azar. Eu instalei há muito tempo, então você terá que fazer isso sozinho :)

Por que precisamos do Maven?

Maven é uma ferramenta de construção de projeto, junto com Gradle e Ant. Só porque irei utilizá-lo no JRTB (JavaRush Telegram Bot), quero atualizá-los. Hoje em dia nenhum projeto se faz sem um sistema de montagem, pois simplifica muitas vezes a nossa vida. Isso permite:

• • extrair todas as bibliotecas necessárias (em termos de ferramentas para montagem - dependências (ou seja, dependência));
• • determinar exatamente como o projeto precisa ser compilado e em que (por exemplo, queremos construir um WAR ou JAR ou um JAR executável);
• • definir a versão do projeto em um local para que seja indicada durante a montagem;
• • descrever o projeto e seu ciclo de vida;
• • adicionar os chamados plugins (versão tradicional da palavra inglesa Plugin);
• • publicar bibliotecas em um repositório compartilhado para que outros projetos possam acessá-las como dependências.

Em geral, ele faz muitas coisas e todas são úteis. Direi o seguinte: para engenheiros novatos não é necessário conhecer todas as funcionalidades de ponta a ponta. Aqui, como acontece com o git, é importante compreender os conceitos básicos e gerais. Isto é o que faremos. Para nós, o Maven começa com um arquivo XML na raiz do nosso projeto chamado pom.xml . Faremos tudo na prática, então primeiro criaremos nosso primeiro projeto na Comunidade JavaRush. Para fazer tudo com sabedoria, usarei um template para o repositório , onde já estão configuradas as coisas básicas que descrevi uma vez no JR . Para criar, acesse o repositório com o modelo e clique no botão Usar este modelo : Como resultado, temos o primeiro repositório em nossa comunidade :) Baixamos o projeto localmente. Para fazer isso, através da ideia, vá em Arquivo -> Novo -> Projeto do Controle de Versão . Na janela que aparece, insira um link para o projeto no Github (o resultado será melhor se todos criarem o mesmo projeto separadamente e passarem por todas as etapas comigo): Clique em Clonar e o projeto será clonado .

pom.xml é o chefe de tudo

Tudo que você precisa está em pom.xml. Todas as informações sobre o projeto, seu desenvolvedor e em qual repositório remoto o projeto está armazenado. Inicialmente estamos interessados ​​nos seguintes blocos: <project/> - este é o bloco principal, que contém todas as informações sobre o projeto. Todos os outros estarão explícita ou transitivamente nele. Dentro da tag de abertura diz algo assim:

<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 acima de tudo, a próxima linha também está escrita em todos os pomniks (a gíria é supostamente de pom.xml :)).

<modelVersion>4.0.0</modelVersion>

Mas depois fica mais interessante: descreveremos como identificamos o projeto que o nosso memorial descreve. Usando minha biblioteca como exemplo, irei descrevê-la e depois adicioná-la à nossa memória, ao projeto recém-criado:

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

<name>Image Comparison</name>

O principal aqui:

• • groupId é o identificador da organização de desenvolvimento ou do engenheiro individual. Geralmente é o domínio na ordem inversa. Por exemplo, a conta romankh3 no Github é descrita aqui. É muito importante. Digamos que para o ecossistema Spring seja com.springframework . Desta forma você pode distinguir o projeto original do fork de outra pessoa ou simplesmente pela coincidência do nome do projeto.
• • artifaceId já é o nome de um projeto específico que está descrito nesta memória.
• • version — a versão deste projeto. Tudo aqui está claro como o dia: adicionou novas funcionalidades, corrigiu as antigas, refatorou ou fez outras alterações - aumentou a versão.
• • embalagem - aqui descrevemos como o Maven deve montar nosso projeto. Seja em Jar, ou em War, ou em alguns outros .
• • nome - aqui está um nome mais agradável para o projeto.

Ainda há algumas coisas que não precisam ser preenchidas - o Maven funcionará sem elas - mas se você precisar publicar a biblioteca para uso público, definitivamente vale a pena adicioná-las. O que são essas coisas?

• • caminho para o repositório do projeto, de onde pode ser baixado

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

• • a licença sob a qual este projeto é distribuído. Além disso, pode haver mais de um e, portanto, você precisa configurá-lo desta forma:

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

• • informações sobre os desenvolvedores que criaram/estão criando o projeto:

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

• • bloco scm, que descreve como o projeto pode ser acessado:

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

Depois de descrevermos as informações gerais, podemos adicionar um bloco com dependências:

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

Aqui adicionei duas bibliotecas para teste: elas são sempre necessárias. Como você já deve ter notado, as dependências possuem um Escopo - escopo. No nosso caso , test é especificado , o que significa que simplesmente não veremos essa dependência no código principal. A seguir, para deixar tudo bonito, você pode usar uma tag separada para exibir as versões <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>

Portanto, o bloco de dependência pode ser atualizado usando a construção ${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>

Em seguida vem um grande bloco <build/> , que contém um importante bloco <plugins/> , com o qual você pode personalizar o processo de construção. Você pode adicionar um ou mais plugins dentro do bloco <plugins/> , assim:

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

Aqui você pode ver que adicionei dois plug-ins - maven-source-plugin e maven-javadoc-plugin . Cada um dos plugins possui configurações, atributos (parâmetros) que podem ser definidos, personalizando assim os plugins. Isso será interessante para nós no futuro. Por enquanto, vamos lembrar e seguir em frente. Da mesma forma que para as dependências, colocaremos as versões do plugin em <properties/> . Com base nisso, você pode criar a seguinte memória:

<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 de vida do Maven

Maven tem um ciclo de vida maven. Vale dizer que este é um conjunto de tarefas que um especialista pode realizar. Pode haver outras tarefas além do ciclo de vida do maven. Sobre o que é isso? Existe um conjunto de comandos com os quais você pode montar um projeto ( construir ... de novo, claro, um papel vegetal do inglês, mas sem isso não há lugar), deletar compilações que o Maven coletou, instalar no Maven local para que você possa puxe localmente o projeto como uma dependência e assim por diante. Agora vamos falar sobre tudo com mais detalhes. Antes de escrever a minha opinião sobre estas equipas, resolvi ler o que estavam a escrever na Internet sobre este assunto... e percebi que era muito difícil descrever. Para o trabalho, para o trabalho inicial, precisamos de vários comandos . Vamos descrevê-los:

• • compilar — compila o projeto. Esta é a primeira etapa: durante ela você pode ver se há algum erro de compilação no projeto. Às vezes, há vários avanços no trabalho no IDEA, e é por isso que problemas de compilação aparecem onde não deveriam existir. Portanto, este comando irá pontuar todos os i's.
• • test - executa todos os testes executados no JUnit e localizados onde o Maven os espera ( src/test/java é o seu capitão).
• • package é o próximo comando, que inclui os dois anteriores: ou seja, o comando compile é primeiro lançado dentro dele, depois o comando test é enviado para o projeto compilado , e se tudo estiver bem aqui, a criação de um arquivo é iniciada (o arquivo que selecionamos em <packaging/>))
• • install - quando instalamos o Maven em uma máquina, temos um repositório Git local que armazena as bibliotecas que baixamos para os projetos. Mas a beleza do Maven é que podemos usar o comando install para adicionar nosso projeto a um repositório Git local e usar nosso projeto localmente como uma dependência. Não acredite em mim? Experimente :) Desta forma você poderá ver rapidamente como seu projeto ficará como uma dependência de outro.
• • implantar é a coroa de tudo o que veio antes. Um comando que permite adicionar um projeto não apenas a um repositório local como instalação, mas também a um remoto, de onde todos com acesso podem utilizá-lo como dependência.
• • verify - um comando que irá verificar tudo e informar se o projeto está pronto para implantação.
• • limpo - é claro, os arquivos compilados e o arquivo devem ser armazenados em algum lugar. Maven tem uma pasta de destino para isso . Esses são dados que o projeto não precisa. E antes de remontar o projeto, seria bom apagar tudo o que veio antes. É para isso que serve o comando clean .

Plug-ins Maven

Queria falar mais sobre plugins, mas o artigo já é longo. Este será seu dever de casa. Entenda o que é e como usá-lo. Na continuação do artigo, trataremos do Maven na prática.

Uma lista de todos os materiais da série está no início deste artigo.