Maven 2 & 3

Environment variables in profile activation not working

Details

  • Type: Bug Bug
  • Status: Closed 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
  • Complexity:
    Intermediate
  • Number of attachments :
    1

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>

Issue Links

Activity

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
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.
Hide
Vincent Siveton added a comment -

Patch applied in r609944. Thanks!

Show
Vincent Siveton added a comment - Patch applied in r609944. Thanks!
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
Vincent Siveton added a comment -

To reinvestigate due to Richard's comment

Show
Vincent Siveton added a comment - To reinvestigate due to Richard's comment
Hide
Brian Fox added a comment -

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

Show
Brian 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.
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.

People

Vote (10)
Watch (9)

Dates

  • Created:
    Updated:
    Resolved: