Perfil de Maven - Activar el perfil según el embalaje

Question

Tengo un POM que declara cosas de la aplicación web que son comunes a mis proyectos. Lo uso como padre para todas las aplicaciones web.

¿Es posible activar un perfil solo cuando el embalaje está en guerra? He intentado el enfoque de propiedad, pero eso no funciona (ya que no es una propiedad del sistema/entorno).

Como esto no funciona, simplemente puedo desactivar ese perfil al instalar el POM, pero me gustaría que fuera más inteligente por sí mismo.

Walter

Answer 1

No hay una manera clara de hacerlo, el módulo principal no tiene forma de conocer el embalaje del niño. (Las soluciones no limpias implicarían crear un complemento que analiza el pom del módulo secundario, etc.)

Answer 2

Sé que esto no está respondiendo a su pregunta directamente, pero la solución habitual para este tipo de problemas es usar la especialización (como ocurre con las clases).

Así que tiene su MasterPom con todo el comportamiento común.

MasterWarPom que amplía MasterPom (es su padre), y coloca aquí las especializaciones de 'embalaje es guerra'.

mismo modo que podría tener MasterJarPom, etc ...

De esta manera las diferencias se dividen a cabo muy bien.

Answer 3

Lo mejor que he podido encontrar para estos escenarios de clases ha sido utilizar un activador de activación basado en archivos. por ejemplo, mi padre tiene pom

<profile> 
    <id>maven-war-project</id> 
    <activation> 
    <file><!-- add a file named .maven-war-project-marker to webapp projects to activate this profile --> 
     <exists>${basedir}/.maven-war-project-marker</exists> 
    </file> 
    </activation> 
    <build> 
    <plugins> 
    <!-- configuration for webapp plugins here --> 
    </plugins> 
    </build> 

y webapp proyectos que heredan de este padre contendrá un archivo 'guerra-proyecto-marcador .maven' que activa el perfil

Esto se ve bastante obtuso, pero funciona con bastante fiabilidad, mientras que - usar la activación de propiedad no es confiable si una persona o sistema diferente construye, - hereda de padres específicos del tipo se volvió un poco engorroso para mí ya que abuelo cambia la versión con relativa frecuencia ya que se usa definir las versiones 'estándar' o preferidas de dep común las dificultades que a su vez requirieron versiones correspondientes de todos los padres específicos del tipo con ningún cambio que no sea la versión de los abuelos

Answer 4

Puede simplemente verificar la existencia de src/main/webapp. Cada aplicación web que utiliza el diseño de directorio estándar Maven debe contener esta carpeta. Para evitar archivos falsos innecesarios.

<profile> 
    <id>custom-profile-eclipse-project-generation-webapp</id> 
    <activation> 
     <file> 
      <exists>${basedir}/src/main/webapp</exists> 
     </file> 
    </activation> 
    <build> 
    </build> 
</profile> 

más preciso también se puede comprobar la existencia de la $ {} basedir /src/main/webapp/WEB-INF/web.xml. Eso debería identificar definitivamente un proyecto de guerra.

Para mí utilizo esta configuración en mi super-pom común para configurar el plugin maven-eclipse para diferentes tipos de proyectos. Eso es muy útil para obtener configuraciones de eclipse homogéneas sobre el mismo tipo de proyecto en nuestra organización, especialmente cuando los desarrolladores ejecutan eclipse: eclipse en proyectos de varios módulos.

Answer 5

¿Probar de esta manera?

paquete mvn -Dmaven.test.skip = true -Dwar

<project ×××××> 
<modelVersion>4.0.0</modelVersion> 
<parent> 
    <groupId>××××</groupId> 
    <artifactId>×××××</artifactId> 
    <version>×××××</version> 
    <relativePath>../../</relativePath> 
</parent> 
<artifactId>×××××</artifactId> 
<name>${project.artifactId}-${project.version}</name> 
<description>${project.artifactId}-${project.version}</description> 
<properties> 
    <packaging.type>jar</packaging.type> 
</properties> 
<profiles> 
    <profile> 
     <activation> 
      <property> 
       <name>war</name> 
      </property> 
     </activation> 
     <properties> 
      <packaging.type>war</packaging.type> 
     </properties> 
     <build> 
      <finalName>ROOT</finalName> 
     </build> 
    </profile> 
</profiles> 
<packaging>${packaging.type}</packaging> 
<dependencies> 
    <dependency> 
     ... ... 
    </dependency> 
    ... ... 
</dependencies>