maven-2 - mvn - profiles maven eclipse

Maven-activar el perfil del niño basado en la propiedad

Question

Guión:

1. Dado
   1. Padre POM que define un perfil y un hijo (como módulo)
   2. Proyecto (s) hijo (s) que utilizará el perfil refiriéndose al POM principal.
2. La intención es omitir la ejecución del perfil en el padre y ejecutarlo solo en el hijo.
3. El perfil tiene la sección de activación <activation><property><name>foo</name></property><activation>
4. Dado que el elemento principal no define la propiedad foo , el perfil está inactivo y no se ejecutará para la compilación principal
5. Ahora, estoy definiendo <properties><foo>true</foo></properties> en el niño con la esperanza de que la propiedad se recoja cuando se ejecute la compilación del niño y se active el perfil. No hay tal suerte. El perfil nunca se activa, lo que me dice que la propiedad nunca se establece.
6. Solo para tener en cuenta: el mvn package -Dfoo=true activa el perfil tanto en principal como en secundario

¿Estoy tratando de hacer lo imposible o simplemente hacerlo mal?

PS Hmmm: incluso si defino una propiedad en el padre, el perfil no se activa. ¿Lo que da?

Answer 1

El perfil solo puede ser activado por las propiedades pasadas desde la línea de comando. Esto se debe a que las propiedades en el POM solo se pueden procesar una vez que se ha analizado el POM, momento en el cual es demasiado tarde para resolver la activación del perfil.

Está en un poco de catch-22 con este enfoque a menos que pueda pasar la propiedad desde la línea de comandos, especifique la activación del perfil en su settings.xml (generalmente no es una gran idea), o use la solución en mi anterior Responde para utilizar la presencia de un archivo marcador.

Una alternativa final si está en Maven 2.1.0+ es desactivar el perfil a través de la línea de comandos solo para el POM principal, esto obviamente no es lo ideal.

Puede desactivar un perfil con el carácter ''!'' o así:

mvn install -P !profile-1,!profile-2

Answer 2

Para expandir la respuesta de @ rich-seller y la respuesta automática de @ Bostone, parece imposible tener una configuración en la que el POM principal defina algunos perfiles como alternativas, y los POM secundarios seleccionan uno de estos perfiles de forma predeterminada, mientras que le permiten para anular temporalmente la elección de un niño (es decir, en el CLI). Considere un POM principal para proyectos que usan algún marco y un complemento asociado, cuyas versiones podemos asumir están definidas por propiedades:

<profiles>
<profile>
<id>newest</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<framework.version>2.0</framework.version>
<plugin.version>2.0</plugin.version>
</properties>
</profile>
<profile>
<id>older</id>
<activation>
<property>
<name>older.framework</name>
<value>true</value>
</property>
</activation>
<properties>
<framework.version>1.1</framework.version>
<plugin.version>1.1</plugin.version>
</properties>
</profile>
</profiles>

Ahora, un hijo heredado de este POM principal de forma predeterminada usará 2.0 como cabría esperar, y -Polder o -Dolder.framework=true funcionarán para intentar -Dolder.framework=true con el marco más antiguo (por ejemplo, para probar la compatibilidad). Sin embargo no se puede escribir en el niño POM.

<properties>
<older.framework>true</older.framework>
</properties>

y que el perfil older se active automáticamente. Podría usar la activación basada en archivos para hacer que este módulo se compile contra 1.1 si el newest no estuviera activo de manera predeterminada, pero luego no es fácil ejecutarlo temporalmente contra 2.0: por lo que sé, tanto older perfiles newest older como los newest estarán activos si pasado -Pnewest , por lo que necesita deshabilitar explícitamente otros perfiles, lo que no es razonable si tiene una docena de ellos. Entonces, simplemente no hay solución, excepto copiar la información del perfil en el POM secundario:

<properties>
<framework.version>1.1</framework.version>
<plugin.version>1.1</plugin.version>
</properties>

en el punto en el que -Pnewest no funcionará para anular estas propiedades, por lo que debe usar -Dframework.version=2.0 -Dplugin.version=2.0 .

En otras palabras, los perfiles solo son útiles si todos los módulos secundarios pueden usar el mismo perfil (aquí el newest ) de forma predeterminada. Si algunos de ellos se construyen normalmente con 1.1 y otros con 2.0, los perfiles son inútiles.

Parece que este es un caso de uso para una mejora del núcleo de Maven, o quizás una extensión de compilación de Maven 3. http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators y https://github.com/maoo/maven-tiles vienen a la mente.

Answer 3

Para responder directamente a mi propia pregunta: en la compilación de múltiples módulos, todas las propiedades se configuran antes de ejecutar la compilación, por lo que es imposible activar / desactivar el perfil en uno de los módulos durante la compilación según la configuración de la propiedad en el POM secundario. Sin embargo, si está buscando una forma de hacerlo utilizando otros medios, lea este comentario.