Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To expand on @rich-seller's answer, and @Bostone's self-answer, it seems to be impossible to have a setup where the parent POM defines a few profiles as alternatives, and child POMs select one of these profiles by default, while allowing you to override the choice for a child temporarily (i.e. on the CLI). Consider a parent POM for projects which use some framework and an associated plugin, both of whose versions we can assume are defined by properties:</p> <pre><code>&lt;profiles&gt; &lt;profile&gt; &lt;id&gt;newest&lt;/id&gt; &lt;activation&gt; &lt;activeByDefault&gt;true&lt;/activeByDefault&gt; &lt;/activation&gt; &lt;properties&gt; &lt;framework.version&gt;2.0&lt;/framework.version&gt; &lt;plugin.version&gt;2.0&lt;/plugin.version&gt; &lt;/properties&gt; &lt;/profile&gt; &lt;profile&gt; &lt;id&gt;older&lt;/id&gt; &lt;activation&gt; &lt;property&gt; &lt;name&gt;older.framework&lt;/name&gt; &lt;value&gt;true&lt;/value&gt; &lt;/property&gt; &lt;/activation&gt; &lt;properties&gt; &lt;framework.version&gt;1.1&lt;/framework.version&gt; &lt;plugin.version&gt;1.1&lt;/plugin.version&gt; &lt;/properties&gt; &lt;/profile&gt; &lt;/profiles&gt; </code></pre> <p>Now a child inheriting from this parent POM by default will use 2.0 as you would expect, and <code>-Polder</code> or <code>-Dolder.framework=true</code> will work to try building it with the older framework (e.g. to test compatibility). However you cannot write in the child POM</p> <pre><code>&lt;properties&gt; &lt;older.framework&gt;true&lt;/older.framework&gt; &lt;/properties&gt; </code></pre> <p>and have the <code>older</code> profile be activated automatically. You could use file-based activation to make this module build against 1.1 if <code>newest</code> were not active by default, but then it is not easy to temporarily run it against 2.0: as far as I know both <code>older</code> and <code>newest</code> profiles would be active if you passed <code>-Pnewest</code>, so you need to explicitly <em>disable</em> other profiles which is unreasonable if you have a dozen of them. So there is just no solution except to copy the profile information to the child POM:</p> <pre><code>&lt;properties&gt; &lt;framework.version&gt;1.1&lt;/framework.version&gt; &lt;plugin.version&gt;1.1&lt;/plugin.version&gt; &lt;/properties&gt; </code></pre> <p>at which point <code>-Pnewest</code> will <em>not</em> work to override these properties, so you need to use <code>-Dframework.version=2.0 -Dplugin.version=2.0</code>.</p> <p>In other words, the profiles are only useful if all the child modules can use the same profile (here <code>newest</code>) by default. If some of them are normally built with 1.1 and some with 2.0, the profiles are useless.</p> <p>Seems like this is a use case for a Maven core enhancement, or perhaps a Maven 3 build extension. <a href="http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators" rel="noreferrer">http://docs.codehaus.org/display/MAVEN/Custom+Profile+Activators</a> and <a href="https://github.com/maoo/maven-tiles" rel="noreferrer">https://github.com/maoo/maven-tiles</a> come to mind.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload