Para expandir la respuesta de @ rich-seller, y la auto-respuesta de @Bostone, parece imposible tener una configuración donde el POM padre define algunos perfiles como alternativas, y los POM secundarios seleccionan uno de estos perfiles de forma predeterminada, mientras que le permiten anular la elección de un niño temporalmente (es decir, en la CLI).Considere un POM padres para proyectos que utilizan algún tipo de marco y un plug-in asociado, cuyos dos versiones podemos suponer se definen 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 niño que hereda de este POM matriz por defecto utilizará 2.0 como lo haría espera, y -Polder
o -Dolder.framework=true
trabajará para intentar construirlo con el marco anterior (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 tienen el perfil older
se activará automáticamente. Puede utilizar la activación basada en archivos para hacer que este módulo compile contra 1.1 si newest
no estaban activos por defecto, pero luego no es fácil ejecutarlo temporalmente contra 2.0: por lo que sé, los perfiles older
y newest
estarían activos si pasó -Pnewest
, por lo que necesita explícitamente desactivar otros perfiles que no es razonable si tiene una docena de ellos. Así que simplemente no hay ninguna solución excepto para copiar la información de perfil a la POM niño:
<properties>
<framework.version>1.1</framework.version>
<plugin.version>1.1</plugin.version>
</properties>
momento en el que se -Pnewest
no trabajo para anular estas propiedades, por lo que es necesario utilizar -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í newest
) de manera predeterminada. Si algunos de ellos se construyen normalmente con 1.1 y algunos con 2.0, los perfiles son inútiles.
Parece que esto es un caso de uso para una mejora de núcleo Maven, o tal vez una extensión de construcción Maven 3. http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators y https://github.com/maoo/maven-tiles vienen a la mente.
Sí. Estoy aceptando esto ya que se basa en mi respuesta y generalmente no me gusta aceptar mi propia – Bostone
Información muy útil. Y gracias por el consejo sobre la activación basada en archivos; eso resolvió mi problema muy limpiamente. – Allan