Todo lo que querías saber sobre Maven: "Proyecto Java de la A a la Z"

Hola a todos, queridos amigos. Me gustaría disculparme de inmediato: recuerdo que prometí escribir un artículo una vez por semana. No funciono. Simplemente no he conseguido sentarme y escribir correctamente, pero no quiero hacerlo de esta manera o de aquella. No me quejaré de los motivos, ya que no lo necesito y, ciertamente, a usted no le interesa. El proyecto no está muerto, estaba en estasis :) ¡Seguimos! Y el material de hoy está dedicado a Maven.

Hablemos de Maven

Primero necesitas instalarlo. Por supuesto, como tengo una Mac, solo puedo mostrar la instalación para una Mac. Es simplemente mala suerte. Lo instalé hace mucho tiempo, así que tendrás que hacerlo tú mismo :)

¿Por qué necesitamos Maven?

Maven es una herramienta de creación de proyectos, junto con Gradle y Ant. Sólo porque lo usaré en JRTB (JavaRush Telegram Bot), quiero mantenerlos actualizados. Hoy en día no se crea un solo proyecto sin un sistema de montaje, porque nos simplifica la vida muchas veces. Esto permite:

• • obtener todas las bibliotecas necesarias (en términos de herramientas de ensamblaje - dependencias (es decir, dependencia));
• • determinar exactamente cómo se debe ensamblar el proyecto y en qué (por ejemplo, queremos recopilarlo en WAR o JAR o JAR ejecutable);
• • colocar la versión del proyecto en un lugar para que se indique durante el montaje;
• • describir el proyecto y su ciclo de vida;
• • agregar los llamados complementos (versión tradicional de la palabra inglesa Plugin);
• • publicar bibliotecas en un repositorio compartido para que otros proyectos puedan utilizarlas como dependencias.

En general, hace muchas cosas y todas son útiles. Diré esto: para los ingenieros novatos no es necesario conocer todas las funciones de principio a fin. Aquí, al igual que con git, es importante comprender los conceptos básicos y generales. Esto es lo que haremos. Para nosotros, Maven comienza con un archivo XML en la raíz de nuestro proyecto llamado pom.xml . Haremos todo en la práctica, así que primero crearemos nuestro primer proyecto en la comunidad JavaRush. Para hacer todo sabiamente, usaré una plantilla para el repositorio , donde ya están configuradas las cosas básicas que describí una vez en JR . Para crear, vaya al repositorio con la plantilla y haga clic en el botón Usar esta plantilla : Como resultado, tenemos el primer repositorio en nuestra comunidad :) Descargamos el proyecto localmente. Para hacer esto, a través de la idea, vaya a Archivo -> Nuevo -> Proyecto desde Control de versiones . En la ventana que aparece, ingrese un enlace al proyecto en Github (el resultado será mejor si todos crean el mismo proyecto por separado y siguen todos los pasos conmigo): Haga clic en Clonar y el proyecto se clonará .

pom.xml es el jefe de todo

Todo lo que necesitas está en pom.xml. Toda la información sobre el proyecto, su desarrollador y en qué repositorio remoto está almacenado el proyecto. Al principio, nos interesan los siguientes bloques: <proyecto/> - este es el bloque principal, que contiene toda la información sobre el proyecto. Todos los demás estarán en él de forma explícita o transitiva. Dentro de la etiqueta de apertura dice algo como esto:

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

Y además de todo lo demás, la siguiente línea también está escrita en todos los pomniks (la jerga supuestamente proviene de pom.xml :)).

<modelVersion>4.0.0</modelVersion>

Pero luego se vuelve más interesante: describiremos cómo identificamos el proyecto que describe nuestro memorial. Usando mi biblioteca como ejemplo, la describiré y luego la agregaremos a nuestra memoria, al proyecto recién creado:

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

<name>Image Comparison</name>

Lo principal aquí:

• • groupId es el identificador de la organización de desarrollo o del ingeniero individual. Este suele ser el dominio en orden inverso. Como ejemplo, aquí se describe la cuenta romankh3 en Github. Es muy importante. Digamos que para el ecosistema Spring es com.springframework . De esta manera puedes distinguir el proyecto original del fork de otra persona o simplemente por la coincidencia del nombre del proyecto.
• • artifaceId ya es el nombre de un proyecto específico que se describe en esta memoria.
• • versión : la versión de este proyecto. Aquí todo está claro como el día: se agregaron nuevas funciones, se corrigieron las antiguas, se refactorizaron o se realizaron algunos otros cambios, se aumentó la versión.
• • embalaje : aquí describimos cómo Maven debería ensamblar nuestro proyecto. Ya sea en Jar, o en War, o algunos otros .
• • nombre - aquí hay un nombre más agradable para el proyecto.

Todavía hay algunas cosas que no es necesario completar (Maven funcionará sin ellas), pero si necesita publicar la biblioteca para uso público, definitivamente vale la pena agregarlas. ¿Qué son estas cosas?

• • ruta al repositorio del proyecto, desde donde se puede descargar

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

• • la licencia bajo la cual se distribuye este proyecto. Además, puede haber más de uno y, por lo tanto, debes configurarlo de esta manera:

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

• • información sobre los desarrolladores que crearon/están creando el proyecto:

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

• • bloque scm, que describe cómo se puede acceder al proyecto:

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

Después de haber descrito la información general, podemos agregar un bloque con dependencias:

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

Aquí agregué dos bibliotecas para realizar pruebas: siempre son necesarias. Como ya habrás notado, las dependencias tienen un Alcance - alcance. En nuestro caso , se especifica test , lo que significa que simplemente no veremos esta dependencia en el código principal. A continuación, para que todo luzca hermoso, puedes usar una etiqueta separada para mostrar las versiones <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>

Entonces, el bloque de dependencia se puede actualizar usando la construcción ${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>

Luego viene un bloque <build/> grande , que contiene un bloque <plugins/> importante , con el que puedes personalizar el proceso de compilación. Puedes agregar uno o más complementos dentro del bloque <plugins/> , así:

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

Aquí puede ver que agregué dos complementos: maven-source-plugin y maven-javadoc-plugin . Cada uno de los complementos tiene configuraciones, atributos (parámetros) que se pueden configurar, personalizando así los complementos. Esto será interesante para nosotros en el futuro. Por ahora, recordemos y sigamos adelante. De la misma manera que para las dependencias, pondremos las versiones del complemento en <properties/> . En base a esto, puedes crear la siguiente 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 de vida maven

Maven tiene algo llamado ciclo de vida de maven. Vale la pena decir que este es un conjunto de tareas que un experto puede realizar. Puede haber otras tareas además del ciclo de vida de Maven. ¿De qué se trata? Hay un conjunto de comandos con los que puedes ensamblar un proyecto ( compilar ... nuevamente, por supuesto, papel de calco del inglés, pero sin esto no hay ningún lugar), eliminar compilaciones que recopiló Maven, instalar en Maven local para que puedas extraiga localmente el proyecto como una dependencia, y así sucesivamente. Ahora hablemos de todo con más detalle. Antes de escribir mi opinión sobre estos equipos, decidí leer lo que escribían en Internet sobre este asunto… y me di cuenta de que era muy difícil de describir. Para el trabajo, para el trabajo inicial, necesitamos varios comandos . Vamos a describirlos:

• • compilar : compila el proyecto. Esta es la primera etapa: durante la misma podrás ver si hay algún error de compilación en el proyecto. A veces hay varios avances al trabajar en IDEA, por lo que aparecen problemas de compilación donde no deberían existir. Entonces este comando pondrá los puntos en todas las íes.
• • test : ejecuta todas las pruebas que se ejecutan en JUnit y están ubicadas donde Maven las espera ( src/test/java es su capitán).
• • paquete es el siguiente comando, que incluye los dos anteriores: es decir, primero se ejecuta el comando de compilación dentro de él, luego el comando de prueba se envía al proyecto compilado y, si todo está bien aquí, comienza la creación de un archivo. (el archivo que seleccionamos en <paquete/>))
• • instalar : cuando instalamos Maven en una máquina, tenemos un repositorio Git local que almacena las bibliotecas que descargamos para proyectos. Pero lo bueno de Maven es que podemos usar el comando de instalación para agregar nuestro proyecto al repositorio Git local y usar nuestro proyecto localmente como una dependencia. ¿No me crees? Pruébalo :) De esta manera podrás ver rápidamente cómo tu proyecto se verá como una dependencia de otro.
• • desplegar es la corona de todo lo que vino antes. Un comando que brinda la posibilidad de agregar un proyecto no solo a un repositorio local como instalación, sino también a uno remoto, desde donde todos los que tengan acceso pueden usarlo como una dependencia.
• • verificar : un comando que comprobará todo y dirá si el proyecto está listo para su implementación.
• • limpio - por supuesto, los archivos compilados y el archivo comprimido deben almacenarse en algún lugar. Maven tiene una carpeta de destino para esto . Estos son datos que el proyecto no necesita. Y antes de volver a montar el proyecto, sería bueno borrar todo lo que vino antes. Para esto sirve el comando clean .

Complementos de Maven

Quería hablar más sobre complementos, pero el artículo ya es largo. Esta será tu tarea. Entiende qué es y cómo utilizarlo. A continuación, analizaremos Maven en la práctica.

Al principio de este artículo encontrará una lista de todos los materiales de la serie.