Maven
  1. Maven
  2. MNG-2848

Environment variables in profile activation not working

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.4, 2.0.5
    • Fix Version/s: 2.0.9
    • Component/s: Profiles
    • Labels:
      None
    • Environment:
      Windows XP Professional, JDK 1.5

      Description

      When using an environment variable as a profile activation variable, it doesnt work, using either env.X or $

      {env.X}

      doesnt work.
      I found the same issue on the forums unresolved.

      http://www.nabble.com/profile-activation-based-on-environment-variables-tf2585492s177.html#a7208580

      Basically, the following doesnt work, where FOO is a windows environment variable (like PATH for example) :

       
       <profile>
        <id>haroon-workstation</id>
        <activation>
          <property>
            <name>env.FOO</name>
            <value>foo</value>
          </property>
         </activation>
          .......
      
       </profile> 
      
      1. MNG-2848.patch
        5 kB
        Richard van der Hoff

        Issue Links

          Activity

          Muhammad Yahia created issue -
          Jason van Zyl made changes -
          Field Original Value New Value
          Fix Version/s Reviewed [ 13555 ]
          Hide
          k added a comment - - edited

          Has there been any resolution to this issue? I am currently also trying to access environment variables from within <profile> (be it within profiles.xml and pom.xml) with no success. Outside of <profile>, I can access environment variables just fine, but within <profile>, using the environment variable as an activation property, does not seem to work.

          I've been unsuccessful trying to access the variable using the following methods within <profile>:
          env.FOO
          FOO
          $

          {env.FOO}

          $

          {FOO}

          Any information reguarding this issue would be greatly appreciated... especially since this has been an issue for well over a year now (referring to http://jira.codehaus.org/browse/MNG-2276 ).

          Defining the variable via the commandline interface does work however, as stated in the link above.

          Btw, my version of maven is 2.0.7

          Show
          k added a comment - - edited Has there been any resolution to this issue? I am currently also trying to access environment variables from within <profile> (be it within profiles.xml and pom.xml) with no success. Outside of <profile>, I can access environment variables just fine, but within <profile>, using the environment variable as an activation property, does not seem to work. I've been unsuccessful trying to access the variable using the following methods within <profile>: env.FOO FOO $ {env.FOO} $ {FOO} Any information reguarding this issue would be greatly appreciated... especially since this has been an issue for well over a year now (referring to http://jira.codehaus.org/browse/MNG-2276 ). Defining the variable via the commandline interface does work however, as stated in the link above. Btw, my version of maven is 2.0.7
          Maria Odea Ching made changes -
          Link This issue is related to MNG-1753 [ MNG-1753 ]
          Hide
          Richard van der Hoff added a comment -

          Here's a patch, against maven-core 2.0.8, which makes profile activation via environment variables work.

          Show
          Richard van der Hoff added a comment - Here's a patch, against maven-core 2.0.8, which makes profile activation via environment variables work.
          Richard van der Hoff made changes -
          Attachment MNG-2848.patch [ 31618 ]
          Hide
          Siveton Vincent added a comment -

          Patch applied in r609944. Thanks!

          Show
          Siveton Vincent added a comment - Patch applied in r609944. Thanks!
          Siveton Vincent made changes -
          Fix Version/s Reviewed Pending Version Assignment [ 13555 ]
          Status Open [ 1 ] Closed [ 6 ]
          Fix Version/s 2.0.9 [ 13801 ]
          Resolution Fixed [ 1 ]
          Assignee Vincent Siveton [ siveton ]
          Fix Version/s 2.1-alpha-1 [ 13143 ]
          Hide
          Richard van der Hoff added a comment -

          Oops, this seems to have broken property passing in mvn exec:java - see MEXEC-41

          Show
          Richard van der Hoff added a comment - Oops, this seems to have broken property passing in mvn exec:java - see MEXEC-41
          Hide
          Siveton Vincent added a comment -

          To reinvestigate due to Richard's comment

          Show
          Siveton Vincent added a comment - To reinvestigate due to Richard's comment
          Siveton Vincent made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Brett Porter made changes -
          Fix Version/s 2.1-alpha-1 [ 13143 ]
          Hide
          Brian E. Fox added a comment -

          vincent: any way to get this for 2.0.9 this week?

          Show
          Brian E. Fox added a comment - vincent: any way to get this for 2.0.9 this week?
          Hide
          John Casey added a comment -

          Looks like the system-property-setting has been reinstated, and the execution properties are still setup and used internally as specified in the patch. This is probably the best we can expect for now, unless/until we find a way to control the way plugins use (and more importantly, pass on to their delegates) the system properties.

          I'm closing this issue. We can open a new one later if we need to fine-tune this behavior further.

          Show
          John Casey added a comment - Looks like the system-property-setting has been reinstated, and the execution properties are still setup and used internally as specified in the patch. This is probably the best we can expect for now, unless/until we find a way to control the way plugins use (and more importantly, pass on to their delegates) the system properties. I'm closing this issue. We can open a new one later if we need to fine-tune this behavior further.
          John Casey made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Assignee Vincent Siveton [ siveton ] John Casey [ jdcasey ]
          Hide
          Richard van der Hoff added a comment -

          Yes, agreed that this seems the most sensible approach for now.

          Thanks for sorting this, guys.

          Show
          Richard van der Hoff added a comment - Yes, agreed that this seems the most sensible approach for now. Thanks for sorting this, guys.
          Mark Thomas made changes -
          Project Import Sun Apr 05 08:49:45 UTC 2015 [ 1428223785911 ]
          Mark Thomas made changes -
          Workflow jira [ 12713381 ] Default workflow, editable Closed status [ 12753193 ]
          Mark Thomas made changes -
          Project Import Sun Apr 05 21:45:26 UTC 2015 [ 1428270326204 ]
          Mark Thomas made changes -
          Workflow jira [ 12950281 ] Default workflow, editable Closed status [ 12986503 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Closed Closed
          317d 13h 8m 1 Siveton Vincent 08/Jan/08 06:11
          Closed Closed Reopened Reopened
          6d 16h 26m 1 Siveton Vincent 14/Jan/08 22:37
          Reopened Reopened Closed Closed
          56d 16h 46m 1 John Casey 11/Mar/08 15:24

            People

            • Assignee:
              John Casey
              Reporter:
              Muhammad Yahia
            • Votes:
              10 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development