Your path is the concatenation of the system path followed by the user path. Additionally, system environment variables may not contain references to user environment variables, and any such references will not be expanded. To get the desired result, insert the reference to %JAVA_HOME% in the user environment variable PATH, or create such a variable if it doesn't already exist.
Perhaps a simplified example will make this clearer. Suppose the SYSTEM environment is
ProgramFiles = C:\Program Files
SystemRoot = C:\WINDOWS
PATH = %SystemRoot%\SYSTEM32
and the User JSmith's environment is
JAVA_HOME = %ProgramFiles%\Java\bin
USERPROFILE = C:\USERS\JSmith
PATH = %JAVA_HOME%\bin;%USERPROFILE%\bin
then the resulting path would be
C:\WINDOWS\SYSTEM32;C:\Program Files\Java\bin;C:\Users\JSmith\bin
as desired.
UPDATE NO.2 - Now to the actual question: Why do nested, user-created variables fail to expand?
There's some general problems concerning variable expansion in Windows. I've already run into the same problem and found no clear, reproducible circumstances - the recursion level at which expansion fails is not consistent, special characters don't seem to play a role, etc.
The only viable workaround I found is adding variables recursion level by recursion level. That means: Try deleting all variables you want to nest into each other (including calls from PATH to your user-defined variables), and then start up from scratch. Define your basic variables (etc. ANT-HOME), commit, check if it's expanded, if it is, go on with the next level commit, check... you get the idea.
UPDATED ANSWER - Defining permanent environment variables using the CLI and GUI - Scroll down for the original answer
GUI method:
On Windows 7, just type "system" in the META-Prompt and you'll see an entry "Edit the System Environment Variables". From there, click "Environment variables". There, you can either edit the system variable PATH (bottom list) or add/edit a new PATH variable to the user environment variables.
Command line method:
To change environment variables permanently, you have to use the SETX command in the Windows command line. Unlike in other versions of Windows, it comes built-in with Windows 7. Its syntax differs a lot from SET, but it's also powerful. You'll have to be a bit careful though, it's easy to make a mess of your variables with SETX.
By default, you change user variables. You can have a PATH user environment variable that happily coexists with the system PATH variable. If you don't have it defined yet, do so by typing: SETX PATH yourpath
You can also add a value to the system variable PATH. To do this, you first need to bring up a command line with admin privileges. To do this, hit the Meta(Windows) key, type cmd
and hit CTRL
+ SHIFT
+ENTER
and confirm the UAC dialog.
To add new values to path, you can now enter
setx path "%path%;yournewpath" /m
It's important to follow that syntax! If you don't include %path% first, all existing values of path will be lost and replaced with only you new path.
The /m switch at the end sets the variable in the system environment.
Please note that you'll have to bring up a new command line to make use of your new variable.
There's also a full reference for SETX at TechNet.
OLD ANSWER
The command SET updates the variables only for the duration of the current command line session.
The correct syntax for adding a value to a variable is 'set [variable]=%[variable]%;[new value]`
Note that left of the equal sign, you have to omit the percent signs!
Source: TechNet Command-line reference for Windows Server
Best Answer
The User and System paths are combined when users log in to the system. If no user is logged in, the %PATH% variable will reflect only the System path.
User variables are configured on a per-user basis, and only take effect when that particular user is logged in.
The System variable apply to all users on the system. The various Windows directories and the Java subsystem, plus others that should apply to all users, are set as part of the System path.
You shouldn't do this because it may not be supported by all programs. Just specify the full paths as most programs expect, and you should be fine.
There should be no XML in your %PATH% variables because the
<
and>
characters, which are used extensively in XML, are invalid directory variables.Some old DOS programs may have trouble with this, but I haven't experienced any problems with spaces in path elements since Windows XP. Just make sure that every path you specify that includes spaces in directory names is enclosed within quotation marks. The document you referenced, that recommends this practice, appears to be outdated as it discusses Java v1.5 (Java v1.6 has been available for many years now, and Java v1.7 is anticipated by many to be released very soon).