This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Product Version = NetBeans IDE Dev (Build 201206040001) Operating System = Windows 7 version 6.1 running on x86 Java; VM; Vendor = 1.7.0_04 Runtime = Java HotSpot(TM) Client VM 23.0-b21 Prior to NB 7.2 I coudl configure the working directory for running my project (Maven JavaSE project) using and environment variable. E.g. set Working directory to ${env.MY_FOLDER} where MY_FOLDER is an environment variable. I also have the same path set as a NB variabel so I tried ${var.MY_FOLDER} as well. Starting in NB 7.2 I get this error: run: C:\Users\scott.palmer\AppData\Local\NetBeans\Cache\dev\executor-snippets\run.xml:52: C:\Program Files (x86)\NetBeans Dev 201206040001\${env.MY_FOLDER} is not a valid directory at org.apache.tools.ant.taskdefs.Java.setupWorkingDir(Java.java:855) at org.apache.tools.ant.taskdefs.Java.setupExecutable(Java.java:825) But the funny thing is that if I flip it from ${var.MY_FOLDER} to ${env.MY_FOLDER} it will work ONCE immediately after changing the run config, and then it will continue to fail after that.
The solution seems to be to remove the "var." entirely.. Setting up of variables seems to be quite different in 7.2. Now they are called "Ant Variables" and they have no prefix.
do you have a sample setup you can attach to the issue? I must admin I'm a bit lost and don't understand what the problem is and how to reproduce? please note that the C:\Users\scott.palmer\AppData\Local\NetBeans\Cache\dev\executor-snippets\run.xml:52 path is to an ANT script, so most likely you are using the Compile on Save feature here. Please try supressing it temporarily in project properties..
(In reply to comment #0) > > But the funny thing is that if I flip it from ${var.MY_FOLDER} to > ${env.MY_FOLDER} it will work ONCE immediately after changing the run config, > and then it will continue to fail after that. the fact that once it works and then not, might be an indication that Compile on Save is indeed involved. When project changes, we always execute maven. Just to be able to accomodate the various potential changes done to the build. Any successive executions are done via the ant based CoS executor. I'd like to reiterate that a sample project is essential to resolve the issue. tzezula, jlahoda: anything changed in the CoS ant runner lately (7.2)?
Created attachment 120663 [details] Sample project that uses environment variable to set working directory The attached project tries to run in a directory specified by an environment variable named KAYAK_SDK. First run works, second run complains that /${env.KAYAK_SDK} is not a valid directory.
Thank you for the sample project. I can confirm that disabling the Compile on Save feature makes it run correctly all the time. (CoS is set in project properties Compile panel).
(In reply to comment #1) > The solution seems to be to remove the "var." entirely.. Setting up of > variables seems to be quite different in 7.2. Now they are called "Ant > Variables" and they have no prefix. From looking at the code, we've always taken the "Variables" with var. prefix and that seems to still be working. These props never got the env. prefix inside the action mappings or poms. so using ${KAYAK_SDK} and putting KAYAK_SDK into Ant variables dialog still works in both plain Maven execution and in CompileOnSave execution as well.
If you use the var. prefix it DOES NOT work. I only noticed this because stuff that was working for me before with NB 7.1.2 stopped working. I think it may have been related to CoS getting turned on automatically in the 7.2 update - I'm not certain.
http://hg.netbeans.org/core-main/rev/a85f82998a27 this should include environment variables and also properties from active configuration into the map with replacement tokens for evaluation of expressions in the actions definitions
Integrated into 'main-golden', will be available in build *201206140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/a85f82998a27 User: Milos Kleint <mkleint@netbeans.org> Log: #213684 next to system properties, also return environment variables as replacement tokens. additionally add all properties from active configuration as well. These come last, effectively having the highest priority
I'm seeing the effects of this again in 7.2 RC 1 In the VM Options field of my projects Run configuration I have: -Xincgc "-Xbootclasspath/a:${env.JDK_HOME}/jre/lib/jfxrt.jar" If I change that line slightly and run it works. If I then run again it fails For example, I can change it to: -Xincgc "-Xbootclasspath/a:%JDK_HOME%/jre/lib/jfxrt.jar" and it will work for one run, then fail after that. In these cases it appears that the bootclasspath isn't being set as I've specified. I can also change it to: -Xincgc "-Xbootclasspath/a:C:\Program Files (x86)\Java\jdk1.7.0_06/jre/lib/jfxrt.jar" and it will run one time but the fail (for a different reason) with: run: Error: Could not find or load main class Files Java Result: 1 BUILD SUCCESSFUL (total time: 0 seconds) In this case it seems the arguments are not parsed properly due to spaces. But why were they the first time? All of these seem to be behaving the same as this bug originally was, where the first run works and subsequent runs are broken.
(In reply to comment #10) > I'm seeing the effects of this again in 7.2 RC 1 I think the reason is that this fix got into the repository after branching
swpalmer: can you verify the assumption made by mmirilovic by downloading the development build? if it works, resolve the issue again and I will proceed with backporting it to 7.2 release branch. thank you.
(In reply to comment #12) > swpalmer: can you verify the assumption made by mmirilovic by downloading the > development build? if it works, resolve the issue again and I will proceed with > backporting it to 7.2 release branch. thank you. ping? application of the patch depends on your the verification in dev builds. Thank you.
You want me to tell you when you branched your code? Why don't you could look at the code or Mercurial logs?
fine, closing as fixed in 7.3 then.