Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-3328

Allow multiple profile activation properties.

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.8
    • Fix Version/s: 3.x / Backlog
    • Component/s: Profiles
    • Labels:
      None

      Description

      The pom model should be changed to allow multiple properties to activate a profile. So the profile activation section could look something like this:

      <activation>
        <properties>
          <my-prop-1>some-value</my-prop-1>
          <my-prop-2>another-value</my-prop-2>
        </properties>
      </activation>
      

      This would provide more flexibility in profile activation.

        Issue Links

          Activity

          Hide
          elifarley@yahoo.com Elifarley Callado Coelho added a comment -

          Maybe adding support for boolean operators would be nice. Here is an example:


          <activation>

          <and>
          <property><name>prop-1</name></property>

          <property><name>prop-2</name></property>

          <property><name>prop-3</name></property>

          <or>
          <property><name>prop-4</name></property>

          <not>
          <property><name>prop-5</name></property>
          </not>

          <property><name>prop-6</name></property>

          <os>MacOS</os>

          </or>

          </and>

          </activation>

          Show
          elifarley@yahoo.com Elifarley Callado Coelho added a comment - Maybe adding support for boolean operators would be nice. Here is an example: — <activation> <and> <property><name>prop-1</name></property> <property><name>prop-2</name></property> <property><name>prop-3</name></property> <or> <property><name>prop-4</name></property> <not> <property><name>prop-5</name></property> </not> <property><name>prop-6</name></property> <os>MacOS</os> </or> </and> </activation> —
          Hide
          pgier Paul Gier added a comment -

          For better compatibility with the current maven model, the syntax for this should look more like this:

          <activation>
            <property>
              <name>my-prop-1</name>
              <value>some-value</value>
            </property>
            <property>
              <name>my-prop-2</name>
              <value>another-value</value>
            </property>
          </activation>
          

          If either of these properties match the given value, the profile should be activated.
          In addition, the other activators (os, jvm, file, etc) should also be allowed to have multiple values.

          Show
          pgier Paul Gier added a comment - For better compatibility with the current maven model, the syntax for this should look more like this: <activation> <property> <name>my-prop-1</name> <value>some-value</value> </property> <property> <name>my-prop-2</name> <value>another-value</value> </property> </activation> If either of these properties match the given value, the profile should be activated. In addition, the other activators (os, jvm, file, etc) should also be allowed to have multiple values.
          Hide
          nessche Marco Sandrini added a comment - - edited

          boolean operators could be achieved with the following syntax (let's assume with want to express the condition ((a && b) || (c && d)) )

          <activations>
            <activation>
              <properties>
                <property>
                  <name>my-prop-A</name>
                  <value>valueA</value>
                </property>
                <property>
                  <name>my-prop-B</name>
                  <value>valueB</value>
                </property>
              </properties>
            </activation>
            <activation>
              <properties>
                <property>
                  <name>my-prop-C</name>
                  <value>valueC</value>
                </property>
                <property>
                  <name>my-prop-D</name>
                  <value>valueD</value>
                </property>
             </properties>
            </activation>
          </activations> 
          

          so all the conditions within one activation are considered as an AND and the different activation elements are considered as an OR. The downside of this proposal is of course that it would break the current POM model.

          Show
          nessche Marco Sandrini added a comment - - edited boolean operators could be achieved with the following syntax (let's assume with want to express the condition ((a && b) || (c && d)) ) <activations> <activation> <properties> <property> <name> my-prop-A </name> <value> valueA </value> </property> <property> <name> my-prop-B </name> <value> valueB </value> </property> </properties> </activation> <activation> <properties> <property> <name> my-prop-C </name> <value> valueC </value> </property> <property> <name> my-prop-D </name> <value> valueD </value> </property> </properties> </activation> </activations> so all the conditions within one activation are considered as an AND and the different activation elements are considered as an OR. The downside of this proposal is of course that it would break the current POM model.
          Hide
          aguizar Alejandro Guizar added a comment -

          Activating a profile based on EITHER property matching the given values is already possible, just copy the profile. If you want to avoid duplication simply use XML entities. What is not currently possible is to activate a profile based on ALL properties matching the given values.

          I would like that the following snippet meant "if all properties match the given values, the profile should be activated".

          <activation>
            <property>
              <name>my-prop-1</name>
              <value>some-value</value>
            </property>
            <property>
              <name>my-prop-2</name>
              <value>another-value</value>
            </property>
          </activation>
          
          Show
          aguizar Alejandro Guizar added a comment - Activating a profile based on EITHER property matching the given values is already possible, just copy the profile. If you want to avoid duplication simply use XML entities. What is not currently possible is to activate a profile based on ALL properties matching the given values. I would like that the following snippet meant "if all properties match the given values, the profile should be activated". <activation> <property> <name> my-prop-1 </name> <value> some-value </value> </property> <property> <name> my-prop-2 </name> <value> another-value </value> </property> </activation>
          Hide
          gary.fry gary fry added a comment - - edited

          Would be great if you could marry OS and Properties as an AND condition.

          For example,

             <activation>
               <os>
                 <family>unix</family>
               </os>
               <property>
                 <name>my-prop-2</name>
                 <value>another-value</value>
               </property>
             </activation>
           

          Currently, Maven2 looks for the first condition that is true, and the profile is activated. However, this is not very useful if the build needs to run in both Windows and Unix environments and you need to do something slightly different on each OS, where activation is also determined by a property being set at buld time

          Show
          gary.fry gary fry added a comment - - edited Would be great if you could marry OS and Properties as an AND condition. For example, <activation> <os> <family> unix </family> </os> <property> <name> my-prop-2 </name> <value> another-value </value> </property> </activation> Currently, Maven2 looks for the first condition that is true, and the profile is activated. However, this is not very useful if the build needs to run in both Windows and Unix environments and you need to do something slightly different on each OS, where activation is also determined by a property being set at buld time
          Hide
          pekarna Ondra Žižka added a comment -

          +1 to Elifarley Callado Coelho for boolean logic,
          -1 to Marco Sandrini for too verbose syntax.

          Show
          pekarna Ondra Žižka added a comment - +1 to Elifarley Callado Coelho for boolean logic, -1 to Marco Sandrini for too verbose syntax.
          Hide
          heuermh Michael Heuer added a comment -

          This issue makes our cross-platform build a mess, tracked as

          Maven profiles appear not to be able to fully discriminate MacOSX 10.6.x, Apple JDK 1.6.x, x86_64
          http://code.google.com/p/piccolo2d/issues/detail?id=151

          Show
          heuermh Michael Heuer added a comment - This issue makes our cross-platform build a mess, tracked as Maven profiles appear not to be able to fully discriminate MacOSX 10.6.x, Apple JDK 1.6.x, x86_64 http://code.google.com/p/piccolo2d/issues/detail?id=151
          Hide
          nicoulaj Julien Nicoulaud added a comment -

          +1 for Marco Sandrini's syntax.

          @Alejandro Guizar: sorry for being offtopic, but what do you mean by "If you want to avoid duplication simply use XML entities" ? Would you have an example ?

          Show
          nicoulaj Julien Nicoulaud added a comment - +1 for Marco Sandrini's syntax. @Alejandro Guizar: sorry for being offtopic, but what do you mean by "If you want to avoid duplication simply use XML entities" ? Would you have an example ?
          Hide
          pulkitsinghal@gmail.com Pulkit Singhal added a comment -

          Why is an enhancement with this many votes being ignored? What is the reason that this is not being considered or scheduled in the pipeline?

          Show
          pulkitsinghal@gmail.com Pulkit Singhal added a comment - Why is an enhancement with this many votes being ignored? What is the reason that this is not being considered or scheduled in the pipeline?
          Hide
          sebastian.koske Sebastian Koske added a comment -

          This request was first entered 3 years ago, when will it ever be honored? I think this is something many developers are waiting for...

          Show
          sebastian.koske Sebastian Koske added a comment - This request was first entered 3 years ago, when will it ever be honored? I think this is something many developers are waiting for...
          Hide
          epabst Eric Pabst added a comment - - edited

          I posted a fix for MNG-4516, which is related.

          Show
          epabst Eric Pabst added a comment - - edited I posted a fix for MNG-4516 , which is related.
          Hide
          kango_v Darren Bell added a comment -

          So, will this one be any time soon?

          Show
          kango_v Darren Bell added a comment - So, will this one be any time soon?
          Hide
          gorgophol Benjamin Haag added a comment -

          Same problem here!
          Costs me days now, to find a workaround, if that is possible.

          What sense does that AND condition make? You could do every AND with several profiles.
          But tell me, is there ANY chance to do an OR condition, as it is described in MNG-4516?

          Bug was for 2.0.8, I'm using 2.2.1 and 3.0.3 and nothing got better ...

          Show
          gorgophol Benjamin Haag added a comment - Same problem here! Costs me days now, to find a workaround, if that is possible. What sense does that AND condition make? You could do every AND with several profiles. But tell me, is there ANY chance to do an OR condition, as it is described in MNG-4516 ? Bug was for 2.0.8, I'm using 2.2.1 and 3.0.3 and nothing got better ...
          Hide
          matthewadams Matthew T. Adams added a comment -

          +1 for conditional operators, especially OR. I could really use this!

          Show
          matthewadams Matthew T. Adams added a comment - +1 for conditional operators, especially OR. I could really use this!
          Hide
          matthewadams Matthew T. Adams added a comment -

          Just noticed that, as of this writing, this issue is #5 in popularity:
          http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Apopularissues-panel

          Can the project get this resourced?

          Show
          matthewadams Matthew T. Adams added a comment - Just noticed that, as of this writing, this issue is #5 in popularity: http://jira.codehaus.org/browse/MNG#selectedTab=com.atlassian.jira.plugin.system.project%3Apopularissues-panel Can the project get this resourced?
          Hide
          c21 Pala Gabriel added a comment -

          Guys this defect is 5 years old now. What the hell are you waiting for ?

          Show
          c21 Pala Gabriel added a comment - Guys this defect is 5 years old now. What the hell are you waiting for ?
          Show
          gabor.liptak Gábor Lipták added a comment - try this: https://github.com/kpiwko/el-profile-activator-extension
          Hide
          rcalmbac Richard Calmbach added a comment -

          Full support for boolean expressions for activation conditions would be really useful. At a minimum, multiple properties should be treated as "AND", the way it was always intended. You can do "OR" by duplicating a profile (ugly but at least possible), but currently, there is no way to do "AND" - a serious limitation.

          Show
          rcalmbac Richard Calmbach added a comment - Full support for boolean expressions for activation conditions would be really useful. At a minimum, multiple properties should be treated as "AND", the way it was always intended. You can do "OR" by duplicating a profile (ugly but at least possible ), but currently, there is no way to do "AND" - a serious limitation.
          Hide
          wigbam Stepan Kolesnik added a comment -

          Please, can this be looked into? So many votes, but zero traction

          Show
          wigbam Stepan Kolesnik added a comment - Please, can this be looked into? So many votes, but zero traction
          Hide
          shout Thomas Repnik added a comment -

          No progress here since 8 years. Could anybody please take a look at it? This would really be a small but very useful improvment.

          Show
          shout Thomas Repnik added a comment - No progress here since 8 years. Could anybody please take a look at it? This would really be a small but very useful improvment.
          Hide
          smaring Steve Maring added a comment -

          disappointing and surprising that this doesn't work yet ... AND/OR capability on property activation would be incredibly useful for handling complex scenarios

          Show
          smaring Steve Maring added a comment - disappointing and surprising that this doesn't work yet ... AND/OR capability on property activation would be incredibly useful for handling complex scenarios
          Hide
          wigbam Stepan Kolesnik added a comment - - edited

          Since Matthew T. Adams made his comment more than 5 years ago this issue has risen up to Top #2 position and yet there has been no activity still. Can someone please explain why this proves to be such a difficult task to do?

          Yesterday I have bitten the bullet and patched Maven locally in less than 2 hours (that's including new tests) to make this feature work on my machine. Therefore knowing that coding is definitely not a show-stopper here, what is it then? Design? I.e. agreeing on the syntax? A few very nice proposals have been made already, some preserving existing model, others extending it. Or is it unwillingness to change the Maven model which this feature ultimately requires?

          Currently I can see several viable approaches to go ahead on this:

          1. Minimum pain: preserve existing Maven model version, and extend it in a backwards compatible manner. All which needs doing is replacing:
            <association>
              <type>ActivationProperty</type>
            </association>
            

            with:

            <association xml.itemsStyle="flat">
              <type>ActivationProperty</type>
              <multiplicity>*</multiplicity>
            </association>
            

            in maven.mdo and settings.mdo plus a few trivial changes to corresponding Java handlers. All existing pom's will be automatically compatible with the new schema.

            The downside: it does not follow Maven model convention as property elements would be declared without corresponding properties wrapper element.

          2. Slightly dirty: preserve existing Maven model version, and extend it in a backwards compatible manner, so that new properties section is added to existing conditions as a separate element. It might look something like this, for example:
            <activation>
              <!-- Old-school -->
              <property>
                <name>my-prop-A</name>
                <value>valueA</value>
              </property>
              <!-- New element -->
              <properties>
                <property>
                  <name>my-prop-B</name>
                  <value>valueB</value>
                </property>
                <property>
                  <name>my-prop-C</name>
                  <value>valueC</value>
                </property>
              </properties>
            </activation>
            

            The new section would be treated as another AND condition to any existing conditions. As with Option #1 all existing pom's out there will be automatically compatible with the new schema since it does not break it, but extends it.

            The downside: it is quite dirty and introduces some redundancy.

          3. More dirty: preserve existing Maven model version, and extend it in a backwards compatible manner, so that new profile activation logic is added as a separate element. Using the proposal by Marco Sandrini it might look something like this, for example:
            <activation>
              <!-- Old-school -->
              <property>
                <name>my-prop-A</name>
                <value>valueA</value>
              </property>
              <!-- New element -->
              <activations>
                <activation>
                  <properties>
                    <property>
                      <name>my-prop-B</name>
                      <value>valueB</value>
                    </property>
                    <property>
                      <name>my-prop-C</name>
                      <value>valueC</value>
                    </property>
                  </properties>
                </activation>
                <activation>
                  <jdk>1.4</jdk>
                  <properties>
                    <property>
                      <name>my-prop-D</name>
                       <value>valueD</value>
                    </property>
                   </properties>
                </activation>
              </activations>
            </activation>
            

            The new section could be named whatever (activations, anyOf etc.) and would be treated as another AND condition to any existing conditions. As with Option #1 all existing pom's out there will be automatically compatible with the new schema since it does not break it, but extends it.

            The downside: it is quite dirty and introduces some redundancy.

          4. Long-term: bump the Maven model version and completely revamp profile activation, add new fancy and/or conditions, possibly multiple file conditions, regex, scripting, blackjack, rocket-boosters etc. Since in this scenario Maven model version is bumped might as well go ballistic.

            The downside: needs a lot of design/discussion/development time to make it happen.

          Of course, for a long-term solution the appropriate way forward would be to go with #4 and completely revamp profile activation. But as things have been stagnant for over a decade on this I believe that the most easy, simple and effective short-term temporary solution which would please 99% of people here is #1. I can submit a patch to make it work as long as this can be reviewed/approved by somebody.

          Show
          wigbam Stepan Kolesnik added a comment - - edited Since Matthew T. Adams made his comment more than 5 years ago this issue has risen up to Top #2 position and yet there has been no activity still. Can someone please explain why this proves to be such a difficult task to do? Yesterday I have bitten the bullet and patched Maven locally in less than 2 hours (that's including new tests) to make this feature work on my machine. Therefore knowing that coding is definitely not a show-stopper here, what is it then? Design? I.e. agreeing on the syntax? A few very nice proposals have been made already, some preserving existing model, others extending it. Or is it unwillingness to change the Maven model which this feature ultimately requires? Currently I can see several viable approaches to go ahead on this: Minimum pain: preserve existing Maven model version, and extend it in a backwards compatible manner. All which needs doing is replacing: <association> <type> ActivationProperty </type> </association> with: <association xml.itemsStyle= "flat" > <type> ActivationProperty </type> <multiplicity> * </multiplicity> </association> in maven.mdo and settings.mdo plus a few trivial changes to corresponding Java handlers. All existing pom's will be automatically compatible with the new schema. The downside : it does not follow Maven model convention as property elements would be declared without corresponding properties wrapper element. Slightly dirty: preserve existing Maven model version, and extend it in a backwards compatible manner, so that new properties section is added to existing conditions as a separate element. It might look something like this, for example: <activation> <!-- Old-school --> <property> <name> my-prop-A </name> <value> valueA </value> </property> <!-- New element --> <properties> <property> <name> my-prop-B </name> <value> valueB </value> </property> <property> <name> my-prop-C </name> <value> valueC </value> </property> </properties> </activation> The new section would be treated as another AND condition to any existing conditions. As with Option #1 all existing pom's out there will be automatically compatible with the new schema since it does not break it, but extends it. The downside : it is quite dirty and introduces some redundancy. More dirty: preserve existing Maven model version, and extend it in a backwards compatible manner, so that new profile activation logic is added as a separate element. Using the proposal by Marco Sandrini it might look something like this, for example: <activation> <!-- Old-school --> <property> <name> my-prop-A </name> <value> valueA </value> </property> <!-- New element --> <activations> <activation> <properties> <property> <name> my-prop-B </name> <value> valueB </value> </property> <property> <name> my-prop-C </name> <value> valueC </value> </property> </properties> </activation> <activation> <jdk> 1.4 </jdk> <properties> <property> <name> my-prop-D </name> <value> valueD </value> </property> </properties> </activation> </activations> </activation> The new section could be named whatever ( activations , anyOf etc.) and would be treated as another AND condition to any existing conditions. As with Option #1 all existing pom's out there will be automatically compatible with the new schema since it does not break it, but extends it. The downside : it is quite dirty and introduces some redundancy. Long-term: bump the Maven model version and completely revamp profile activation, add new fancy and/or conditions, possibly multiple file conditions, regex, scripting, blackjack, rocket-boosters etc. Since in this scenario Maven model version is bumped might as well go ballistic. The downside : needs a lot of design/discussion/development time to make it happen. Of course, for a long-term solution the appropriate way forward would be to go with #4 and completely revamp profile activation. But as things have been stagnant for over a decade on this I believe that the most easy, simple and effective short-term temporary solution which would please 99% of people here is #1. I can submit a patch to make it work as long as this can be reviewed/approved by somebody.

            People

            • Assignee:
              Unassigned
              Reporter:
              pgier Paul Gier
            • Votes:
              97 Vote for this issue
              Watchers:
              81 Start watching this issue

              Dates

              • Created:
                Updated:

                Development