pom.xml y settings.xml
Se puede decir que Pom.xml y Setting.xml son los dos archivos de configuración más importantes en Maven, lo que determina las funciones centrales de Maven. Aunque los artículos anteriores mencionaron el contenido en pom.xml y settings.xml en fragmentos, todos se mencionan brevemente, y el aprendizaje y la investigación no son detallados. El propósito de este artículo es estudiar estos dos archivos de configuración importantes en detalle. Estos dos archivos de configuración pueden conducir a muchos temas de Maven.
Coordenadas maven
Primero, hablemos de por qué necesitamos usar coordenadas de Maven.
El mundo Maven tiene una gran cantidad de componentes, es decir, algunos jares, guerra y otros archivos que generalmente se usan. Antes de que Maven presente el concepto de coordenadas para estos componentes, no podemos usar ningún método para identificar de manera única todos estos componentes. Por lo tanto, si necesita usar dependencias de primavera, vaya al sitio web oficial de Spring para buscar; Si necesita usar dependencias log4j, vaya al sitio web oficial de Apache para buscar. Debido a los diferentes estilos de cada sitio web, se dedica mucho tiempo a buscar y navegar en las páginas web. Sin normas y reglas unificadas, el trabajo no puede automatizarse y la mano de obra repetitiva debe dejarse en las máquinas.
Maven define un conjunto de reglas: cualquier componente en el mundo puede ser identificado de manera única por las coordenadas Maven. Los elementos de coordenadas de Maven incluyen GroupID, ArtifactId, Versión, Empaque y Clasificador. Ahora, siempre que proporcionemos las coordenadas de elementos correctos, Maven puede encontrar el componente correspondiente. En cuanto a dónde descargar, Maven tiene una dirección incorporada de un almacén central "http://repo1.maven.org/maven2". El almacén central contiene la mayoría de los componentes populares del proyecto de código abierto en el mundo. Mavne los descargará cuando sea necesario. Por supuesto, también puede configurar su propia dirección central de almacén y descargar componentes en su propio almacén central.
Por ejemplo, el contexto de la primavera:
<Spendency> <MoupRoupId> org.springframework </groupid> <artifactid> spring-context </artifactid> <verSerse> 4.2.6.Release </versión> </dependencia
Eche un vistazo a los elementos del subordinado:
Este es más o menos el concepto de coordenadas Maven. Comprender las coordenadas de Maven es un paso muy importante para comprender a Maven.
Dependencia transitiva
¿Qué es la dependencia transitiva? Tome la primavera como ejemplo. Cuando use Spring, confiará en otras bibliotecas de clase de código abierto. Hay dos formas de hacer esto:
1. Descargue un paquete .zip grande que contiene todos los frascos de primavera, pero hacerlo a menudo presenta muchas dependencias innecesarias
2. Solo descargue los paquetes .zip relacionados con la primavera, no incluya dependencias. Al usarlos, agregue otras dependencias requeridas de acuerdo con la información de error.
Obviamente, ambos enfoques son muy problemáticos, y el mecanismo de dependencia transitiva de Maven resuelve bien este problema. Abra el pom.xml de Spring-Core-4.1.0.lelease, e intercepto una parte clave:
<dependencies> <dependency> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> <version>1.9</version> <scope>compile</scope> <optional>true</optional> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <Persion> 1.1.3 </versión> <cope> compilar </cope> </pendency> ... </dependencias>
Por ejemplo, el Proyecto A depende del núcleo de primavera, el núcleo de primavera depende de los bienes básicos de los bienes comunes y el registro de los comunes, por lo que Commons-Codec y Commons-Reging son dependencias transitivas del Proyecto A. Con el mecanismo de dependencia transitiva, al usar el núcleo de primavera, no tiene que considerar de qué depende, y no tiene que preocuparse por las dependencias innecesarias. Maven analizará cada POM de dependencia directa e introducirá las dependencias indirectas necesarias en el proyecto actual en forma de dependencias transitivas.
Con el mecanismo de dependencia transitiva, por un lado, simplifica y facilita enormemente la declaración de dependencia. Por otro lado, en la mayoría de los casos, solo necesitamos preocuparnos por cuáles son las dependencias directas del proyecto y no necesitamos considerar qué dependencias transitivas serán introducidas por estas dependencias directas. Sin embargo, a veces las dependencias transitivas también tendrán algunos problemas. En este momento, necesitamos borrar el camino desde el cual se introdujo la dependencia transitiva. Esto se llama mediación de dependencia. Hay dos principios principales de mediación de dependencia:
1. A-> b-> c-> x (1.0), a-> d-> x (2.0), en este momento, hay dos versiones de x en las dos rutas de dependencia. En este momento, se prefiere la ruta más cercana, por lo que X (2.0) se analizará y usará.
2. Las longitudes de dependencia de a-> b-> y (1.0), a-> c-> y (2.0), y (1.0) e y (2.0) son las mismas. A partir de Maven2.0.9, la primera declaración sigue la prioridad, es decir, se prefiere la dependencia con el orden más alto.
Excluir dependencias
Las dependencias transitivas introducirán implícitamente muchas dependencias en el proyecto, lo que simplifica en gran medida la gestión de las dependencias del proyecto, pero a veces esta característica también puede causar problemas. Por ejemplo, hay una situación:
El proyecto actual depende de A. A depende de la versión instantánea de otra biblioteca de clase por alguna razón. Entonces esta instantánea se convertirá en una dependencia transitiva del proyecto actual. En segundo lugar, la inestabilidad de la instantánea afectará directamente el proyecto actual. En este momento, la instantánea debe ser excluida y se declara una versión de lanzamiento formal de la biblioteca de clases en el proyecto actual.
Es muy simple excluir las dependencias, echemos un vistazo al método de escritura:
<Spendency> <MoupRid> com.alibaba.rocketmq </proupid> <artifactId> RocketMQ-Client </artifactId> <versión> 3.2.7 </versión> <EXCLUSIONES> <EXCLUSION> <ProupId> Apache-Lang </groupId> <AriFactId> Commons-Lang </artifactid> <//exusion> </excusions> </Dependency>
Aquí introduje la dependencia de RocketMQ, pero no quiero confiar en Apache-Lang en RocketMQ, pero quiero introducir dependencias por mí mismo, por lo que excluí Apache-Lang.
Cabe señalar aquí que al declarar la exclusión, solo se necesitan GroupId y Artifactid, y no se necesitan elementos de versión. Esto se debe a que solo se necesitan GroupId y Artifactid para localizar de manera única una dependencia en el gráfico de dependencia. En otras palabras, en las dependencias analizadas de Maven, es imposible tener dos dependencias con el mismo grupo y artefácido, pero diferentes versiones.
settings.xml
settings.xml es la configuración básica de Maven. Hay muchos elementos, así que echemos un vistazo uno por uno.
1. Proxy
El proxy significa proxy de Maven. Echemos un vistazo al método de escritura:
<Proxies> <Proxy> <id> opcional </id> <activo> true </ activo> <protocol> http </protocol> <sserername> proxyuser </sserername> <borsionsing> proxyPass </borsion> <gest> proxy.host.net </host> <port> 80 </port> <NoProxyHosts> Local.net | Some.host.com </nonproxyhosts> </proxy> </praxies>
Se necesita proxy porque muchas veces su empresa requiere que acceda a Internet utilizando un proxy certificado por seguridad basado en consideraciones de seguridad. En este caso, debe configurar un proxy HTTP para Maven para permitirle acceder al repositorio externo normalmente para descargar los recursos requeridos. Se pueden configurar múltiples elementos proxy en proxies. Si se declaran múltiples elementos proxy, el primer proxy activado entrará en vigencia por defecto. Active es cierto para activar el proxy, el protocolo representa el protocolo proxy utilizado, por supuesto, lo más importante es especificar el nombre de host (host) y el puerto (puerto) correctos. Si el servidor proxy necesita autenticación, configure el nombre de usuario y la contraseña. El elemento no proximado indica qué nombres de host no requieren un proxy. Puedes usar "|" Para separar múltiples nombres de host y también admitir el comodín "*".
2. Repositorio
El repositorio representa el almacén central de Maven, porque aunque los componentes en el almacén remoto predeterminado son muy grandes, siempre habrá momentos en los que no satisfacen nuestras necesidades, y luego se utilizarán otros almacenes centrales. Echemos un vistazo al método de escritura:
<S Repository> <id> public </id> <name> Nexus privado local </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <loteseS> <Dontened> true </etable> </soverions> <napshoots> <pobled> </enable </enable </snaped </snapshots> </reembolsado
Se puede declarar múltiples repositorio. La identificación debe ser única. Preste especial atención a la que la identificación utilizada por el repositorio central con el que Maven viene es central. Si otras declaraciones de repositorio también usan esta ID, la configuración del repositorio central se sobrescribirá. Las versiones y las instantáneas son más importantes. El primero significa abrir el soporte de descarga de la versión de versión para el repositorio, y el segundo significa cerrar el soporte de descarga de la versión de instantánea para el repositorio. De esta manera, Maven irá al repositorio para descargar la versión de lanzamiento del repositorio sin descargar la versión de instantánea del repositorio.
3. Servidor
Se puede acceder a la mayoría de los almacenes remotos sin autenticación, pero a veces se consideran en factores de seguridad y necesitan proporcionar información de autenticación para acceder a algunos almacenes remotos. Para consideraciones de seguridad, la información de autenticación generalmente solo se coloca en settings.xml, y el servidor es el elemento de autenticación. Eche un vistazo a la configuración:
<vero> <di> Nexus-Leleases </id> <sserername> implementment </sserername> <bassword> implementment </shanting> </servidor>
La clave aquí es la identificación. Esta ID debe ser exactamente la misma que la ID del elemento Repositiry que necesita ser autenticado. En otras palabras, la identificación formal vincula la información de autenticación y la configuración del repositorio.
4. Mirror
Si Warehouse X puede proporcionar todo el contenido almacenado en el almacén Y, entonces el almacén X puede considerarse como un espejo de Warehouse Y. En otras palabras, cualquier componente que se pueda obtener de Y se puede obtener de X. Por ejemplo, "http://maven.net.cn/content/groups/public/" es un warehouse central es un warehouse central "http://repo1.maven.org/maven2/" en China. Debido a los factores de ubicación geográfica, el espejo a menudo puede proporcionar servicios más rápidos que el almacén central, por lo que se utiliza el espejo.
Eche un vistazo a la configuración de Mirror:
<Mirror> <id> nexus </id> <name> Repositor de nexo interno </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <prorof>*</prorof> </prorror>
En este ejemplo, Mirrorf es *, lo que indica que la configuración es un espejo para todos los repositorios centrales, y cualquier solicitud para el repositorio central se transferirá al espejo. Los otros tres elementos ID, nombre y URL no son diferentes de la configuración general del almacén, que representa el identificador, el nombre y la dirección del almacén de espejo. Del mismo modo, si la imagen requiere autenticación, la autenticación del repositorio también se puede configurar en función de la ID.
Gracias por leer, espero que pueda ayudarte. ¡Gracias por su apoyo para este sitio!