Configuración del núcleo Maven (principio de proximidad / prioridad de configuración)

Resumen:

1. Conceptos básicos de maven
2. configuración del núcleo maven

 

1. Instalación de Maven y conceptos básicos

Resumen:

1. instalación maven
2. compilación maven
3. Ejecutar caso de prueba (prueba)
4. paquete maven
5. gestión perezosa de maven

1. Instalación:

1. Descargue Maven desde el sitio web oficial ( http://maven.apache.org/download.cgi )
2. Descomprime el directorio especificado
3. Configure la variable de entorno MAVEN_HOME PATH
4. Compruebe si la instalación es exitosa (mvn -version)

¿Qué es maven? ¿Cuál es su función básica? La gestión de compilaciones , paquetes , pruebas y dependencias intuitivamente siente el proceso de compilación y empaquetado de Maven.

 

http://maven.apache.org/pom.html

2. Compilación de Maven

Demostración del proceso de compilación de Maven

l Crear un proyecto maven.

l Crear archivo src

l Escribir archivos pom

l ejecuto el comando de compilación

 

Escribir la configuración básica del archivo pom

<project xmlns = "http://maven.apache.org/POM/4.0.0"

  xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"

  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> org.codehaus.mojo </groupId>

  <artifactId> mi-proyecto </artifactId>

  <version> 1.0.SNAPSHOT </version>

</project>

 

#mvn compilar comando

mvn compilar

 

---------------------------

[INFO] No hay fuentes para compilar

[INFO] ----------------------------------------------- ----------------

[INFORMACIÓN] CONSTRUIR ÉXITO

[INFO] ----------------------------------------------- ----------------

[INFO] Tiempo total: 0.473 s

[INFO] Terminado en: 2018-08-05T15: 55: 44 + 08: 00

[INFO] Memoria final: 6M / 153M

[INFO] ----------------------------------------------- ----------------

 

 

Tenga en cuenta que en la configuración y los comandos anteriores, no hemos especificado dónde están los archivos de origen. ¿Dónde está la compilación final? Aqui

Maven utiliza el método acordado para obtener el código fuente y los archivos de recursos de la estructura del proyecto para su compilación y empaquetado.

1. Archivo fuente principal: $ {project} / src / main / java
2. Archivo de recursos principal: $ {project} / src / main / resources
3. Archivo fuente de prueba: $ {project} / src / test / java
4. Archivo de recursos de prueba: $ {project} / src / test / resources

Mueva el archivo java al directorio src / main / java y vuelva a compilar.

mv src / hello.java /src/main/java/hello.java

mvn compilar;

3. Embalaje Maven

Maven demo demo

#mvn Comandos de empaquetado

paquete mvn

4. Demostración de prueba de la unidad Maven

l Escribir clase de prueba

l ejecutar comando de prueba

 

 

 

Compila la clase de prueba

# Crear directorio de prueba

mkdir -p / src / test / java

# Escribir clase de prueba

vim TestHello.java

# Código de prueba ------------------------

paquete com.test.tuling;

TestHello clase pública {

        public void sayHelloTest () {

                System.out.println ("ejecutar prueba .....");

        }

}

Ejecutar instrucción de prueba:

# Prueba de ejecución

prueba mvn

Después de ejecutar el comando, encontramos que nuestro método de prueba no se ejecutó. ¿Por qué? La razón es que la clase de prueba en Maven ha hecho un contrato, y el contrato debe ser el nombre de la clase al comienzo de la Prueba y el método al comienzo de la prueba que se ejecutará.

Después de volver a modificar el nombre del método, ejecute mvn test para ejecutarlo normalmente.

paquete com.test.tuling;

TestHello clase pública {

        pruebas públicas nulasayHelloTest () {

                System.out.println ("ejecutar prueba .....");

        }

}

 

Normalmente, compilamos casos de prueba a través de junit, y luego necesitamos agregar dependencias de junit.

5. Gestión de dependencia de Maven

l Agregar dependencia junit en el archivo pom

l Modificar la clase de prueba, agregar código junit

l ejecutar comando de prueba

Únete a la configuración

<dependencias>

<dependencia>

  <groupId> junit </groupId>

  <artifactId> junit </artifactId>

  <version> 4.0 </version>

  <scope> prueba </scope>

</dependency>

</dependencies>

 

Modifique la clase de prueba para introducir la clase junit.

// Introduce la clase junit

import org.junit.Assert;

import org.junit.Test;

Assert.assertEquals ("", "hola");

Nota: Cuando agreguemos junit a classPath, el método original que comienza con test no se ejecutará, y debe agregarse con la anotación @Test para que se ejecute.

 

Haz una pregunta

¿Dónde estaba el tarro junit en la demostración justo ahora? ¿Cómo se agregó a classPath? Maven debe importar dinámicamente el paquete junit jar del almacén local en el momento de ejecutar el comando de prueba. Si no puede encontrarlo, irá al almacén remoto para descargarlo y luego importarlo.

 

 

 

 

 

Almacén remoto predeterminado:

El almacén remoto predeterminado de Maven Central está configurado en 

maven-model-builder-3.2.1.jar \ org \ apache \ maven \ model \ pom-4.0.0.xml 位置

Ubicación del almacén local:

La ubicación del almacén local está en ~ / .m2 / respository por defecto

Para modificar $ {M2_HOME} /conf/settings.xml para especificar el directorio del almacén

<! - Especifique el directorio del almacén local->

 <localRepository> G: \. m2 \ repository </localRepository>

 

Resumen de las funciones principales de maven:

1. El papel principal de maven es compilar, probar y empaquetar.
2. El archivo pom.xml en el directorio raíz establece el ID del grupo y el artifactId.
3. Maven obtiene el código fuente y los archivos de recursos del proyecto en función del método acordado para compilar y empaquetar.
4. Para los componentes de los que depende el proyecto y la referencia del almacén local, si el almacén local no existe, se descargará del almacén central.

Dos, configuración del núcleo maven

Resumen:

1. El proyecto es perezoso (interno, externo)
2. Proyecto de agregación y herencia
3. Configuración de construcción del proyecto

El proyecto es vago

La dependencia del proyecto significa que Maven administra el ClassPath del proyecto a través de las características de propagación de dependencia, prioridad de dependencia, dependencias opcionales, exclusión de dependencias y alcance de las dependencias.

 

1. Depende de las características de propagación:

Nuestro proyecto generalmente necesita depender de componentes de terceros, y los componentes de terceros dependerán de otros componentes. En este caso, Maven agregará todos los nodos en la red dependiente a ClassPath. Esta es la característica de propagación de dependencia de Maven.

n Demostración de la red de dependencia de Spring MVC

<! - Añadir spring web mvc demo->

<dependencia>

    <groupId> org.springframework </groupId>

    <artifactId> spring-webmvc </artifactId>

    <version> 4.0.4.RELEASE </version>

</dependency>

 

En la demostración anterior, el proyecto dependía directamente de spring-webmvc llamado dependencia directa, y la dependencia del registro en común se pasó a través de webmvc, por lo que se llamó dependencia indirecta.

2. Confíe en el principio de prioridad

Debido a las características de propagación de dependencia, toda la red dependiente será muy compleja, y es inevitable que aparezcan diferentes versiones del mismo componente. Maven elegirá primero una de estas versiones basándose en el principio de dependencia.

El primer principio: el camino más corto primero.

El segundo principio: la prioridad se coloca primero en el mismo camino.

n Demostración del primer principio.

<! - Añadir commons-logging directamente->

<dependencia>

    <groupId> commons-logging </groupId>

    <artifactId> commons-logging </artifactId>

    <version> 1.2 </version>

</dependency>

En el ejemplo anterior, commons-logging depende de 1.1.3 a través de spring-webmvc, y depende directamente de 1.2 en el proyecto. Basado en el principio del camino más corto, el proyecto finalmente introdujo la versión 1.2.

n Demostración del segundo principio:

Pasos:

1. Agregar un nuevo proyecto Proyecto B
2. Configure el Proyecto B para que dependa de spring-web.3.2.9.
3. El proyecto actual depende directamente del Proyecto B

 Después de la configuración, el proyecto de proyecto actual A tiene dos rutas que pueden depender de spring-web. La que elija depende del orden de configuración de webmvc y Project B.

  Proyecto A ==> spring-webmvc.4.0.0.RELEASE ==> spring-web.4.0.0.RELEASE

  Proyecto A ==> Proyecto B 1.0.SNAPSHOT ==> spring-web.3.2.9.RELEASE

 

 

Nota: En el mismo archivo pom, el segundo principio no está adaptado. La siguiente configuración, la referencia final es la versión 1.2, en lugar de la versión anterior 1.1.1.

 <! - Agregado registro de comunes antes de 1.2->

<dependencia>

    <groupId> commons-logging </groupId>

    <artifactId> commons-logging </artifactId>

    <version> 1.1.1 </version>

</dependency>

 

<dependencia>

    <groupId> commons-logging </groupId>

    <artifactId> commons-logging </artifactId>

    <version> 1.2 </version>

</dependency>

3. Dependencias opcionales

La dependencia opcional significa que esta dependencia no es necesaria. Al agregar <opcional> verdadero </ opcional> a <dependencia>, no es opcional por defecto. No se pasarán dependencias opcionales.

l Demostrar los efectos de las dependencias opcionales.

 

 

4. Eliminar la dependencia

Es decir, se excluye la dependencia indirecta especificada. Especifique los componentes especificados configurando <exclusiones>.

 

 

 

<! - Excluir elementos especificados->

<exclusiones>

    <exclusión>

       <groupId> org.springframework </groupId>

       <artifactId> spring-web </artifactId>

    </exclusion>

</exclusions>

l Demostrar la eliminación de dependencias.

5. Rango de dependencia (ALCANCE)

Para componentes como junit, solo necesitamos usarlos al ejecutar casos de prueba, por lo que no es necesario compilar junit.jar en el paquete.

Esto se puede lograr a través de la configuración del alcance de dependencia de Mave <scope>. maven admite los siguientes cuatro rangos de dependencia en total:

compilar (predeterminado): compila el alcance, dependen tanto la compilación como el paquete.

proporcionado: Proporciona el alcance, depende del tiempo de compilación, pero no se empaquetará. Tales como: servlet-api.jar 

 

 

Tiempo de ejecución: alcance del tiempo de ejecución, dependiendo del empaquetado, la compilación no lo hará. Tales como: mysql-connector-java.jar

prueba: probar el alcance, compilar y ejecutar dependencias de casos de prueba, no se empaquetará. Tales como: junit.jar

sistema: indica que está especificado por CLASSPATH en el sistema. Depende del tiempo de compilación y no se empaquetará. Usado con <systemPath>. Ejemplo: tool.jar en java.home

El sistema se puede usar para importar paquetes desde el classpath del sistema, y ​​también se puede usar para importar frascos de terceros que no están incluidos en el maven del sistema. La práctica es colocar frascos de terceros en el directorio lib del proyecto y luego configurar rutas relativas, pero el sistema no empaquetará Entre así que necesita usarlo con el complemento maven-dependency-plugin. Por supuesto, se recomienda que aún instale manualmente el Jar de terceros en el almacén.

 

<! - La forma habitual de usar el sistema->

<dependencia>

          <groupId> com.sun </groupId>

          <artifactId> herramientas </artifactId>

          <version> $ {java.version} </version>

          <scope> system </scope>

          <opcional> verdadero </optional>

          <systemPath> $ {java.home} /../ lib / tools.jar </systemPath>

</dependency>

 

<! - system Además, use el jar directamente en el proyecto->

<dependencia>

    <groupId> jsr </groupId>

    <artifactId> jsr </artifactId>

    <version> 3.5 </version>

    <scope> system </scope>

    <opcional> verdadero </optional>

    <systemPath> $ {basedir} /lib/jsr305.jar </systemPath>

</dependency>

<! - Empaquete el tarro del sistema a través del complemento. ->

<plugin>

    <groupId> org.apache.maven.plugins </groupId>

    <artifactId> maven-dependency-plugin </artifactId>

    <version> 2.10 </version>

    <ejecuciones>

        <ejecución>

            <id> dependencias de copia </id>

            <phase> compilar </phase>

            <objetivos>

                <goal> dependencias de copia </goal>

            </goals>

            <configuración>

<outputDirectory> $ {project.build.directory} / $ {project.build.finalName} / WEB-INF / lib </outputDirectory>

                Sistema <includeScope> </includeScope>

                <excludeGroupIds> com.sun </excludeGroupIds>

            </configuration>

        </execution>

    </executions>

</plugin>

 

# Únete manualmente al almacén local

mvn install: install-file -Dfile = abc_client_v1.20.jar -DgroupId = tuling -DartifactId = tuling-client -Dversion = 1.20 -Dpackaging = jar

 

Proyecto de agregación y herencia

1. Agregación

 Se refiere a la integración de múltiples módulos juntos, construcción unificada, para evitar construir uno por uno. La agregación requiere un proyecto primario y luego use <modules> para configurar cuál corresponde a la ruta relativa del proyecto secundario

<módulos>

    <module> tuling-client </module>

    <module> tuling-server </module>

</modules>

n Configuración de agregación de demostración

 2. Herencia

La herencia significa que el proyecto secundario hereda directamente las propiedades, dependencias, complementos y otras configuraciones en el proyecto principal para evitar configuraciones repetidas.

1. Herencia de la propiedad:
2. Herencia de dependencia:
3. Herencia del complemento:

Los tres subproyectos de configuración anteriores se pueden reescribir. Después de reescribir, prevalecerán los subproyectos.

 3. Gestión de dependencias

A través de la función de herencia, el subproyecto puede depender indirectamente de las dependencias del proyecto principal, pero las dependencias de múltiples subproyectos a veces no son uno a uno. Introducido en el proyecto.

 

<! -Declare junit 4.12 en el proyecto padre->

<DependencyManagement>

    <dependencias>

        <dependencia>

            <groupId> junit </groupId>

            <artifactId> junit </artifactId>

            <version> 4.12 </version>

        </dependency>

    </dependencies>

</dependencyManagement>

<! - Introducido en subproyecto->

<dependencia>

    <groupId> junit </groupId>

    <artifactId> junit </artifactId>

</dependency>

4. Propiedades del proyecto:

Puede simplificar la configuración configurando parámetros de propiedad a través de <properties>.

<! - Configurar propiedad proName->

<propiedades>

    <proName> ddd </proName>

</properties>

<! - Método de referencia->

$ {proName}

propiedades predeterminadas de maven

directorio raíz del proyecto $ {basedir} 

$ {version} indica la versión del proyecto; 

$ {project.basedir} 同 $ {basedir}; 

$ {project.version} indica la versión del proyecto, que es lo mismo que $ {version}; 

$ {project.build.directory} directorio de compilación, el valor predeterminado es target 

$ {project.build.sourceEncoding} indica el formato de codificación del código fuente principal; 

$ {project.build.sourceDirectory} representa la ruta de origen principal; 

$ {project.build.finalName} indica el nombre del archivo de salida; 

$ {project.build.outputDirectory} El directorio de salida del proceso de compilación, el valor predeterminado es target / classes

 

Configuración de construcción del proyecto

1. Crear asignación de recursos
2. Compila el complemento
3. perfil especifica el entorno de compilación

 

Crear asignación de recursos

Ejemplo de configuración básica:

<defaultGoal> paquete </defaultGoal>

<directory> $ {basedir} / target2 </directory>

<finalName> $ {artifactId} - $ {versión} </finalName>

Descripción:

defaultGoal, la meta o fase predeterminada al ejecutar la compilación, como jar: jar o package, etc.

directorio, la ruta donde se encuentra el resultado de la compilación, el valor predeterminado es el directorio $ {basedir} / target

finalName, el nombre del resultado final de la compilación, el nombre se puede cambiar en otros complementos

 

 

<resources> ejemplo de configuración

<recursos>

   <recurso>

      <directory> src / main / java </directory>

      <incluye>

         <include> ** / *. MF </include>

         <include> ** / *. XML </include>

      </includes>

      <filtering> verdadero </filtering>

   </resource>

   <recurso>

      <directory> src / main / resources </directory>

      <incluye>

         <include> ** / * </include>

         <include> * </include>

      </includes>

      <filtering> verdadero </filtering>

   </resource>

  </resources>

Descripción:

l recursos, archivos de recursos involucrados en el proceso de construcción

¡  targetPath , la ruta de destino del archivo de recursos

¡  directorio , la ruta del archivo de recursos, ubicado de manera predeterminada en el directorio $ {basedir} / src / main / resources /

¡  incluye , un conjunto de patrones de coincidencia de nombre de archivo, los archivos de recursos coincidentes serán procesados ​​por el proceso de compilación

¡  excluye , el proceso de compilación ignorará un patrón coincidente para un conjunto de nombres de archivos y archivos de recursos coincidentes. Se ignorarán los archivos de recursos que coincidan tanto con las inclusiones como con las exclusiones.

¡  filtrado: el valor predeterminado es falso, verdadero significa que $ {key} en el archivo de recursos se cambia dinámicamente en tiempo de compilación a través del parámetro. La fuente se puede reemplazar: el valor de <properties> en Dkey and pom o el archivo de propiedades especificado en <filters>.