Profilo Maven - Attivazione del profilo in base alla confezione

Question

Possiedo un POM che dichiara le applicazioni Web comuni ai miei progetti. Lo uso come genitore per tutte le applicazioni web.

È possibile attivare un profilo solo quando la confezione è in guerra? Ho provato l'approccio delle proprietà, ma ciò non funziona (in quanto non è una proprietà di sistema/ambiente).

Dato che questo fallisce, posso semplicemente disabilitare quel profilo durante l'installazione di POM, ma mi piacerebbe che fosse più intelligente da solo.

Walter

Answer 1

Non c'è un modo pulito per farlo, il modulo genitore non ha modo di conoscere la confezione del bambino. (Le soluzioni non pulite implicano la creazione di un plug-in che analizza il pom del modulo figlio ecc.)

Answer 2

So che questo non risponde direttamente alla tua domanda, ma la solita soluzione per problemi come questo è usare solo la specializzazione (come con le classi).

Così hai il tuo MasterPom con tutti i comportamenti comuni.

MasterWarPom che estende MasterPom (è un genitore) e inserisce qui le specializzazioni di "imballaggio è guerra".

Allo stesso modo si potrebbe avere MasterJarPom, ecc ...

In questo modo le differenze sono divisi piacevolmente.

Answer 3

Il meglio che ho potuto ottenere per questi scenari di ordinamenti è stato quello di utilizzare un trigger di attivazione basato su file. ad esempio il mio pom genitore ha

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

e webapp progetti che ereditano da questo genitore contenere un file chiamato 'guerra-progetto-marcatore .maven' che attiva il profilo

Questo sembra piuttosto ottusa, ma - l'utilizzo dell'attivazione della proprietà non è affidabile se una persona o un sistema diverso crea la build, - l'ereditarietà da genitori specifici del tipo diventa un po 'macchinosa per me poiché la versione di nonno cambia la frequenza relativamente frequentemente in cui viene utilizzata per definire 'standard' o versioni preferite del dep comune le fazioni che a loro volta richiedevano le versioni corrispondenti di tutti i genitori specifici del tipo senza modifiche diverse dalla versione grandparent

Answer 4

Si può semplicemente verificare l'esistenza di src/main/webapp. Ogni applicazione Web che utilizza il layout di directory standard Maven dovrebbe contenere questa cartella. Così eviti i file fittizi non necessari.

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

più precisa si può anche verificare l'esistenza di $ {} basedir /src/main/webapp/WEB-INF/web.xml. Ciò dovrebbe identificare in modo definitivo un progetto di guerra.

Per quanto mi riguarda, utilizzo questa configurazione nel mio super-pom comune per configurare il plugin maven-eclipse per diversi tipi di progetto. Questo è molto utile per ottenere configurazioni omogenee di eclissi sullo stesso tipo di progetto nella nostra organizzazione, specialmente quando gli sviluppatori eseguono direttamente eclipse: eclipse su progetti multi-modulo.

Answer 5

Provare in questo modo?

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