Mac vs. Windows: Reading environment variable in Ant build files

I've got a project that references environment variables in the Ant build file.

<property environment="env" />
<!-- RESOLVE -->
<target name="{target}">
	<if>
		<isset property="env.MY_HOME"/>
		<then>
			<property name="my.home" value="${env.MY_HOME}"/>
		</then>
		<else>
			<property name="my.home" value="${env.USERPROFILE}/me"/>
		</else>
	</if>	
</target>

Other developers on Windows machines don't even have to define the env.IVY_HOME or env.USERPROFILE variables. But I, as a Mac user, am getting the following error during the build process:

settings file does not exist

Now, I have successfully added and echoed IVY_HOME and even USERPROFILE in my .bash_profile file but I still get that same error.

UPDATE: Even the environment variables in my pom.xml aren't being read:

<systemPath>${env.JAVA_HOME}/lib/myJarFile.jar</systemPath>	

If I make changes in my build.xml file even my repo doesn't pick up that the file has been changed. Why would that be? I'm guessing ANT properties are immutable.

I have to hardcode the path to get it to work:

<systemPath>{pathToMyJar}</systemPath>

Why would me, as a Mac user, run into this issue whereas Windows users don't even have to set the environment variables and can still build fine?

UPDATE:
It works for my Windows colleagues because there is a default USERPROFILE environment variable. But, on a Mac, the equivalent is $HOME. How can I fix that? I have tried export USERPROFILE=$HOME in my .profile and .bash_profile files but it's still trying to read env.USERPROFILE.

Here it is in mybuild.xml (I guess another ant file that is triggered for local development from build.xml):

<target name="init-my-stuff">
	<if>
		<isset property="env.MY_HOME"/>
		<then>
			<property name="my.home" value="${env.MY_HOME}"/>
		</then>
		<else>
			<property name="my.home" value="${env.USERPROFILE}/me"/>
		</else>
	</if>	

</target>

This example works on my Mac. The build.xml is similar to the one in your question. I'm using Ant 1.9.6, Ivy 2.5.0, and Ant Contrib 1.0b3.

To test, I'm using the following run.sh in Bash. It is fairly basic, so it will be a useful test to see if it works for you:

#!/bin/bash

unset IVY_HOME
unset USERPROFILE

# try either of these:
# export IVY_HOME=~/tools/apache-ivy/apache-ivy-2.5.0
export USERPROFILE=~/tools/apache-ivy/apache-ivy-2.5.0

ant init-ivy 

Of course, you will have to change the paths to be specific for your machine. By commenting out IVY_HOME or USERPROFILE as appropriate, Ant will use the <then> or <else> branch as expected.

Yes, ant properties are immutable. Once set they cannot be changed anymore. There are ways around this - you can set a variable only for within a single target using the <local> task. for example, or use macros, but that doesn't appear to be relevant for your question, so let's get to the mystery of the missing env.IVY_HOME variable.

On linux/mac in particular, every process gets a brand new fresh 'environment' (in java terms, basically a Map<String, String>), which may be initialized to hold a bunch of extra values if the spawning process decides it wants to do that.

The key point is, if your bash tells you IVY_HOME exists, that does not imply your ant process will see that!

That's what export is for; if you set a property as with IVY_HOME=.... then your shell will not copy that one over to any newly spawned processes. If you stick export in front, it should. One easy enough test is to spawn a bash from within your ant and ask it to print all properties:

<project name="test" default="test">
  <target name="test">
    <exec executable="/bin/bash">
      <arg value="-c" />
      <arg value="set" />
    </exec>
  </target>
</project>

Instructions: Save above to build.xml in a new dir, then run ant.

run the above and I bet that IVY_HOME, USERPROFILE etc aren't in the list in the first place, which suggests that you did not 'set' these properties in the first place. Either you did not export them, or, you're running into a different problem, the concept of 'interactive variables' and 'non-interactive variables'. This isn't baked into the sysenv system, but into most linux/mac setups of shells: There are a whole bunch of shell scripts that are read in when a new shell is started. THere's ~/.bashrc, ~/.profile, etc/bash_profile, /etc_profile, sometimes an /etc/profile.d dir with many scripts, and more.

Which ones actually get invoked when you fire up a shell depends on what shell you're firing up and whether it is 'interactive' or not. It is quite possible you've added export IVY_HOME=.... to a file that isn't even being read in.

Environment variables you want globally available should probably go in ~/.profile.

You can always tell bash to specifically pass some env vars to your process. Try this:

FOO=hello ant

in the same dir as the invoke bash -c set as a test script above. That's one way you can force the issue; by running IVY_HOME=/path/to JAVAHOME=/path/to ant build or whatnot (any equals-sign-separated string put in front of a command tells bash to put that key/value pair into the hashmap it is making for that process).

If that last one still doesn't result in your ant script picking up env.IVY_HOME, then something really weird is going on, and it's time to paste the full script, I think.