Profil Maven - Activer le profil en fonction de l'empaquetage

Question

J'ai un POM qui déclare une application web commune à mes projets. Je l'utilise comme parent pour toutes les applications Web.

Est-il possible d'activer un profil uniquement lorsque l'emballage est en guerre? J'ai essayé l'approche de la propriété, mais cela ne fonctionne pas (car ce n'est pas une propriété système/environnement).

Puisque cela échoue la construction, je peux simplement désactiver ce profil lors de l'installation du POM, mais je voudrais qu'il soit plus intelligent par lui-même.

Walter

Answer 1

Il n'y a pas de moyen propre de faire cela, le module parent n'a aucun moyen de connaître l'emballage de l'enfant. (Les solutions non propres impliquent la création d'un plugin qui analyse le module POM du module enfant, etc.)

Answer 2

Je sais que cela ne répond pas directement à votre question, mais la solution habituelle pour des problèmes comme celui-ci est d'utiliser simplement la spécialisation (comme les classes).

Donc, vous avez votre MasterPom avec tous les comportements communs.

MasterWarPom qui étend MasterPom (c'est son parent), et mettre toutes les spécialisations 'emballage est la guerre' ici.

vous pourriez même avoir MasterJarPom, etc ...

De cette façon, les différences sont divisés en bien.

Answer 3

Le meilleur que j'ai pu trouver pour ces scénarios de tris a été d'utiliser un déclencheur d'activation basé sur des fichiers. par exemple ma pom-mère a

<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> 

et les projets webapp qui héritent de ce parent contiennent un fichier nommé « .maven-guerre-projet-marqueur » qui active le profil

Cela semble assez obtus, mais fonctionne de manière assez fiable alors que - en utilisant la propriété-activation n'est pas fiable si une personne différente ou un système fait la construction, - héritant de parents spécifiques de type est devenu un peu lourd pour moi comme le grandparent-pom change la version relativement fréquemment car il est utilisé pour définir les versions «standard» ou préférées du dépôt commun terminaisons qui, à leur tour, nécessitaient des versions correspondantes de tous les parents spécifiques sans autre modification que la version grand-parent

Answer 4

Vous pouvez simplement vérifier l'existence de src/main/webapp. Chaque application Web qui utilise la disposition de répertoire standard Maven doit contenir ce dossier. Donc, vous évitez les fichiers inutiles inutiles.

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

Plus précisément, vous pouvez également vérifier l'existence de $ {basedir} /src/main/webapp/WEB-INF/web.xml. Cela devrait définitivement identifier un projet de guerre.

Pour ma part, j'utilise cette configuration dans mon super-pom commun pour configurer maven-eclipse-plugin pour différents types de projets. C'est très pratique pour obtenir des configurations d'éclipses homogènes sur le même type de projet dans notre organisation, en particulier lorsque les développeurs exécutent directement eclipse: eclipse sur des projets multi-modules.

Answer 5

Essayez de cette façon?

mvn package -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>