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.
Yep. Ich nehme das an, da es auf meiner Antwort aufbaut und ich mag es im Allgemeinen nicht, meine eigenen – Bostone
Sehr nützliche Informationen zu akzeptieren. Und danke für den Tipp zur dateibasierten Aktivierung; Das hat mein Problem sehr sauber gelöst. – Allan