2009-10-01 15 views
20

Szenario:Maven - aktivieren Kind Profil basierend auf Eigenschaft

  1. Gegeben
    1. Eltern POM, die ein Profil und ein Kind (als Modul)
    2. Child-Projekt (en), die Verwendung wird definiert das Profil durch Bezugnahme auf das Eltern-POM.
  2. Die Absicht ist Profil Ausführung in der Mutter zu überspringen und es in dem Kind ausführt nur
  3. Profil hat Aktivierungsabschnitt <activation><property><name>foo</name></property><activation>
  4. Da Eltern nicht foo Eigenschaft nicht definiert - das Profil ist inaktiv und wird nicht sein für den Eltern Build ausgeführt
  5. Jetzt definiere ich <properties><foo>true</foo></properties> in dem Kind mit der Hoffnung, dass die Eigenschaft abgeholt wird, wenn Kind Build ausgeführt wird und Profil aktiviert wird. Kein solches Glück. Profil wird nie aktiviert, was mir sagt, dass die Eigenschaft nie gesetzt ist.
  6. Just zu beachten: mvn package -Dfoo=true Profil in Eltern und Kind

Bin ich versuche zu tun, das Unmögliche oder es falsch zu machen aktiviert?

P.S. Hmmm - selbst wenn ich die Eigenschaft im Eltern definieren, wird das Profil nicht ausgelöst. Was gibt?

Antwort

7

Um @ Richone-Antwort zu erweitern, und @ Bostone selbst-Antwort, scheint es unmöglich zu sein, ein Setup, wo die Eltern POM definiert einige Profile als Alternativen, und untergeordnete POMs wählen standardmäßig eines dieser Profile aus, während Sie die Auswahl für ein untergeordnetes Element vorübergehend (dh auf der CLI) überschreiben können.Betrachten wir ein Elternteil POM für Projekte, die einige Rahmen und ein zugehöriges Plugin verwenden, deren beide Versionen wir davon ausgehen, können durch Eigenschaften definiert:

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

Jetzt ein Kind von diesem übergeordneten POM standardmäßig erben wird 2.0, wie Sie verwenden würde expect, und -Polder oder -Dolder.framework=true wird funktionieren, um es mit dem älteren Framework zu bauen (z. B. um Kompatibilität zu testen). Sie können jedoch nicht in dem Kind schreiben POM

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

und haben das older Profil automatisch aktiviert werden. Sie könnten die dateibasierte Aktivierung verwenden, um dieses Modul gegen 1.1 zu bauen, wenn newest nicht standardmäßig aktiv waren, aber dann ist es nicht einfach, es gegen 2.0 zu laufen: Soweit ich weiß sind sowohl older als auch newest Profile aktiv, wenn Sie übergeben -Pnewest, so müssen Sie explizit deaktivieren andere Profile, die unangemessen ist, wenn Sie ein Dutzend von ihnen haben. So gibt es nur außer keine Lösung, um die Profilinformationen für das Kind POM zu kopieren:

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

an welchem ​​Punkt -Pnewest wird nicht Arbeit dieser Eigenschaften außer Kraft zu setzen, so dass Sie -Dframework.version=2.0 -Dplugin.version=2.0 verwenden müssen.

Mit anderen Worten, die Profile sind nur dann nützlich, wenn alle untergeordneten Module das gleiche Profil (hier newest) standardmäßig verwenden können. Wenn einige von ihnen normalerweise mit 1.1 und einige mit 2.0 erstellt werden, sind die Profile nutzlos.

Scheint, als ob dies ein Anwendungsfall für eine Maven-Kern-Erweiterung oder vielleicht eine Maven 3 Build-Erweiterung ist. http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators und https://github.com/maoo/maven-tiles in den Sinn kommen.

+0

Yep. Ich nehme das an, da es auf meiner Antwort aufbaut und ich mag es im Allgemeinen nicht, meine eigenen – Bostone

+0

Sehr nützliche Informationen zu akzeptieren. Und danke für den Tipp zur dateibasierten Aktivierung; Das hat mein Problem sehr sauber gelöst. – Allan

5

Das Profil kann nur durch Eigenschaften aktiviert werden, die von der Befehlszeile übergeben werden. Dies liegt daran, dass Eigenschaften im POM erst verarbeitet werden können, nachdem das POM analysiert wurde. Zu diesem Zeitpunkt ist es zu spät, um die Profilaktivierung aufzulösen.

Sie sind mit diesem Ansatz ein bisschen eine catch-22, es sei denn, Sie können die Eigenschaft über die Befehlszeile übergeben, Profilaktivierung in Ihrer settings.xml angeben (in der Regel keine gute Idee), oder verwenden Sie die Abhilfe in meinem previous answer, um das Vorhandensein einer Marker-Datei zu verwenden.

Eine letzte Alternative, wenn Sie auf Maven 2.1.0+ sind, ist das Profil über die Befehlszeile nur für die Eltern POM deaktivieren, das ist immer noch offensichtlich nicht ideal.

Sie können ein Profil entweder mit dem Zeichen '!' Deaktivieren so - oder ‚‘:

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

Ich hatte Angst, so. Es scheint tatsächlich, dass die Ausführung des Profils eingestellt ist und nicht geändert werden kann, nachdem der Build gestartet wurde (sogar mit der Marker-Datei). Bei Deaktivierung Worauf beziehen sich diese -1 und -2? Wenn ich Eltern und Kind und Profil "build" habe, nehme ich an, dass das Profil auf Eltern gelöscht wird? (In meinen Tests ist es nicht) 'mvn installieren -P! Buiild-1' – Bostone

+0

Ich verstehe es nicht genau. Warum funktionieren die Profil-Trigger '' oder' ' nicht für Sie? –

+0

Das Beispiel ist, zwei Profile zu deaktivieren, die Profil-1 und Profil-2 genannt werden, es gibt keine besondere Bedeutung für -1 oder -2. In Ihrem Fall wäre es einfach 'mvn install -P! Build' –

5

direkt auf meine eigene Frage zu beantworten: in mehreren Modulen bauen alle Eigenschaften festgelegt werden, bevor Build ausgeführt wird, so ist es unmöglich zu aktivieren/deaktivieren Profil in einem der Module während der Build basiert auf der Einstellung der Property im Kind POM. Jedoch, wenn Sie nach Möglichkeit suchen, es mit anderen Mitteln zu tun, bitte read this comment

Verwandte Themen