http://jira.codehaus.org/browse/MNG-5035 makes it hard to test on Linux. Works for me in 7.0 on XP (using Maven 3.0). For a main class, I set working dir to C:\ and a program

        System.out.println( System.getProperty("user.dir") );
        System.out.println(Arrays.toString(new File(System.getProperty("user.dir")).listFiles()));

prints

C:\
[C:\AUTOEXEC.BAT, ...]

as expected. For tests, you cannot set the CWD from the command line; see bug #189117. With the snippet listed there in the POM, I get

C:\DOCUME~1\JESSEG~1\LOCALS~1\Temp
[C:\DOCUME~1\JESSEG~1\LOCALS~1\Temp\....]

as expected. Anyway if you want to use a backslash in an action property you need to escape it: something=c:\\some\\dir

Ok, it's caused by not escaping.

Could the escaping be mentioned in the hint pane at the bottom of the window?
(Reopening for this purpose.)

Also, I wonder where is a docs for what everything can be used in that window.
E.g. "Test file" has test=${packageClassName}
That seems like some NetBeans-specific value.
Is there some list of what _everything_ is being replaced?

I am not the original author so I cannot be sure, but I think there is no such document. Could probably include a summary of special properties. At least some are already offered in the special button to the left of the pane.

*** Bug 202759 has been marked as a duplicate of this bug. ***

Also XML characters like "<" need to be escaped.

My two cents is that Netbeans should escape everything in the box as necessary, not the user.  NB will have to escape for storing in nbactions.xml anyway since the user shouldn't be expected to remember  to escape XML characters just because NB needs it.  What is specified to the right of the "=" should be verbatim the value of the property, including quotes, backslashes, and even leading spaces.  These properties are in turn often injected into properties files, and things get too confusing and error prone when you have to do nested layers of escaping.  Besides, that's yet another thing for the user to keep track of.

(In reply to comment #6)
> What is specified to the right of the "=" should be
> verbatim the value of the property, including quotes, backslashes,
> and even leading spaces

Debatable about the latter two; when the list of properties is presented in a textarea, one possible interpretation is as a java.util.Properties, which requires \ to be escaped as \\ and ignores unescaped leading spaces in values (but does permit = to be present in a key when escaped). Compare the Ant option panel (which is a bit clearer by using the text/x-properties editor kit). A less ambiguous UI might use a JTable or similar to let you add key/value pairs as raw text, though this might make it awkward to insert newlines (*).

As to use of '<', I am not sure this is even possible in key names using the current nbactions.xml format, which uses <key>value</key> syntax; while XML permits most (not all!) characters in text nodes when properly escaped, the same is not true of element names. (See bug #200901 for a similar issue unrelated to action mappings.) Fixing that would require a different persisted format for action mappings, which introduces compatibility and upgrade issues. And of course the Maven CLI parser by its nature cannot handle property names containing '='. But perhaps you were referring only to values.

(*) Assuming the Maven launcher can actually handle such exotic characters. The Unix launcher uses "$@" which implies that it should be safe. No clue how the Windows batch script deals with metachars.

Yup, I was thinking about just the values.  It's reasonable (and expected by most) to have restrictions on property names.

As far as the values are concerned, I'm a big fan of adding them in a way that you don't have to worry about escaping them (for netbeans) so you don't have to worry about nested escaping (for example, a SQL Server JDBC URL that becomes "jdbc:sqlserver://qa-db\\\\dbqa;databaseName=prototype",  note the 1 backslash becomes 4, and that's the simplest case).  But I can live with that so long as it works.

Actually, if the Netbeans "Properties" text area matched the format used in the Jenkins text area so you could just copy/paste between the two, that would be a huge timesaver.  So how about using the same escaping for properties as Jenkins?

I need to bump up the priority because there are two big problems.  First, the text area where you set the properties is not..."idempotent".  That is, if you add a set of properties including "text=foo\\\\bar", it will be remembered as "text=foo\\bar".  The next time you edit a properties the "text" property will be remembered as "text=foo\bar", and so on.  I imagine this can be fixed by re-escaping the properties before putting them in the text area.  The other major problem is that trying to add a property with a blank string as a value the form "emptyString=" doesn't work; the "emptyString" property isn't saved and the only way add it is to modify the xml file directly.

Please forget what I said about making it look like Jenkins.  I just looked at it again.  :)

Not P2 when there is a straightforward workaround: edit nbactions.xml directly.

(In reply to comment #10)
>  The other
> major problem is that trying to add a property with a blank string as a value
> the form "emptyString=" doesn't work; the "emptyString" property isn't saved
> and the only way add it is to modify the xml file directly.

this has been fixed recently as part of issue 205214

(In reply to comment #2)
> 
> Also, I wonder where is a docs for what everything can be used in that window.
> E.g. "Test file" has test=${packageClassName}
> That seems like some NetBeans-specific value.
> Is there some list of what _everything_ is being replaced?

fixed lately by including a list of expressions related to current selection into the Add> button popup menu.

(In reply to comment #10)
> I need to bump up the priority because there are two big problems.  First, the
> text area where you set the properties is not..."idempotent".  That is, if you
> add a set of properties including "text=foo\\\\bar", it will be remembered as
> "text=foo\\bar".  The next time you edit a properties the "text" property will
> be remembered as "text=foo\bar", and so on.  I imagine this can be fixed by
> re-escaping the properties before putting them in the text area.  The other
> major problem is that trying to add a property with a blank string as a value
> the form "emptyString=" doesn't work; the "emptyString" property isn't saved
> and the only way add it is to modify the xml file directly.

fixed in http://hg.netbeans.org/core-main/rev/20fa0ec1ae47

Integrated into 'main-golden', will be available in build *201204260400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/20fa0ec1ae47
User: Milos Kleint <mkleint@netbeans.org>
Log: #189119 stop eating up backslashes

(In reply to comment #0)
> STR:
> 
> A)
> 
> 1) Create a maven project from a quickstart (to have a test file),
> 2) Project properties -> Actions -> Test File -> Set Properties:
>       workingDirectory=C:\
> 3) Open the test file and run IDE's "Test file" action
> 4) Maven build will fail with an error which is probably caused by unescaped \
> or such.
> 

workingDirectory property does nothing within the context of surefire plugin. The definion of the plugin parameter doesn't allow for property passed from cmd line to modify it.. see http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#workingDirectory

in latest dev build I can reproduce what jglick did with exec:exec plugin configuration, the property is named exec.workingdir then. Escaping the backclashes is no longer necessary. Now the content will be written to file as is, so C:\ should be sufficient.

consider fixed, if I missed any of the problems mentioned in the issue, please submit a separate issue, this one is already too long and fragmented. Thank you.