java - example - maven profiles
Maven y módulos dependientes (6)
Con el maestro POM:
~/scratch/pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<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>scratch</groupId>
<artifactId>scratch</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<modules>
<module>nipple</module>
<module>cabbage</module>
</modules>
</project>
Y el módulo POMs:
~/scratch/nipple/pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<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">
<parent>
<artifactId>scratch</artifactId>
<groupId>scratch</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>scratch</groupId>
<artifactId>nipple</artifactId>
<version>1.0-SNAPSHOT</version>
</project>
~/scratch/cabbage/pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<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">
<parent>
<artifactId>scratch</artifactId>
<groupId>scratch</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<groupId>scratch</groupId>
<artifactId>cabbage</artifactId>
<version>1.0-SNAPSHOT</version>
<dependencies>
<dependency>
<groupId>scratch</groupId>
<artifactId>nipple</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
Puedo emitir el mvn package en el directorio raíz después de borrar mi repositorio local y terminar con todos los módulos creados. (En JARs-ish vacíos, pero construidos.)
Maven parece buscar dependencias en el repositorio o en la compilación en curso. No atravesará automáticamente la estructura de su proyecto cuando solo esté creando un único módulo, ya que no es necesario que tenga el proyecto principal en su computadora, y mucho menos un directorio sobre el módulo actual. (La relación padre-hijo no es ni siquiera biyectiva).
Una razón por la que esto es así podría deberse a que el diseño de un directorio donde la ubicación de los módulos sea predecible no es de ninguna manera obligatorio. Incluso es algo común y aceptable que el diseño del ejemplo anterior sea así:
projects
|
+--scratch
| |
| +--scratch-parent
| | |
| | +--pom.xml [The POM of scratch:scratch:1.0-SNAPSHOT]
| |
| +--nipple
| | |
| | +--pom.xml [The POM of scratch:mod1:1.0-SNAPSHOT]
| |
| +--cabbage
| | |
| | +--pom.xml [The POM of scratch:mod2:1.0-SNAPSHOT]
En este caso, la sección <modules> del POM principal sería:
<modules>
<module>../nipple</module>
<module>../cabbage</module>
</modules>
Observe que no hay nada que indique qué ID de artefacto está en qué módulo. Solo sirve para decirle a Maven que estas son ubicaciones de sistemas de archivos donde se pueden buscar otros artefactos relacionados con esta compilación.
Los colegas han estado promocionando las maravillas de Maven y sus dependencias mágicas, pero estoy descubriendo que falla en lo que consideraría el uso obvio.
Supongamos que tengo una carpeta raíz con un POM maestro.
Luego debajo tengo algunos proyectos, llámalos A y B
B requiere A y, por lo tanto, el POM en la carpeta B tiene la entrada de dependencia adecuada
Ahora, de vuelta en la carpeta raíz, en un perfil, especifico que quiero compilar B.
Cuando realizo la instalación habitual de mvn clean, aparece un error porque A no se creó.
Mis amigos me dicen que tengo que especificar tanto A como B en ese perfil principal en la raíz.
Pero no es todo el punto de la gestión de dependencias que maven ve B, va al archivo B POM, donde ve la dependencia de A y, por lo tanto, debe construirse A automáticamente.
Eche un vistazo al complemento del reactor de Maven , en particular reactor: make, que construye un módulo y todos los módulos de los que depende.
La respuesta es que no es así como funciona Maven. La idea detrás de Maven es darle al desarrollador un sistema lógico y simple para controlar las dependencias. Obtener dependencias del repositorio es la clave para esto. Cada excepción debilita este control y simplicidad. Agregar A como una dependencia en el POM principal aborda completamente su escenario sin agregar más excepciones. El uso de archivos por lotes o scripts ant es otra forma de abordar su escenario.
Rich tiene toda la razón. Lo que usted describe generalmente no es el comportamiento esperado. Aunque, según lo establecido por deterb, el reactor de Maven admite compilaciones parciales si los módulos son conocidos por el POM principal .
La construcción con mvn install -pl B -am también debe hacer las dependencias de ( -am ) B (es decir, A).
De todos modos, el módulo A debe ser un módulo del POM principal.
(ver Módulos de Maven + Construcción de un único módulo específico )
Si estás trabajando con IntelliJ, tienen una pequeña casilla mágica: "Resolver los artefactos del área de trabajo" en su configuración de ejecución de Maven. Así que no hay necesidad de instalar ni construir desde el padre.
Una razón por la que puedo pensar que su comportamiento deseado no se ha implementado es la siguiente:
Supongamos que estoy trabajando en los proyectos A y B. Actualmente A está roto. Si la resolución de dependencia ocurriera como quisiera, nunca podría construir B hasta que A se arreglara. Entonces, o bien tengo que revertir mis cambios a A, o concentrarme en arreglar A primero. De cualquier manera, posiblemente no sea en lo que quiero centrarme ahora mismo.
En general, B quiere trabajar con la "última buena" versión de A, en lugar de la última. El uso de las dependencias del repositorio significa que al menos compilaron bien (y, con suerte, las pruebas unitarias también se ejecutaron).