Java JAR creation problems

[pkusbel]

Running the linux version of SlickEdit 2013 (v18.0.1.2 64-bit), with hotfix 12. 

When I try to create a jar file from a class that has nested class (so that there will be a test$foo.class create), jar creation fails.  Looks like SE is trying to escape the $ and it's doing it wrong
Easy to duplicate: just create a new Java with Main project, add a nested class

public class javatest {
    public static void main(String args[]) {
    }
    public class foo{
    }
}

build and make a jar, it fails:
---------- 'make jar' Project: 'javatest.vpj' - 'Debug' ----------
/usr/bin/jar cvf ../test.jar javatest.class javatest/$foo.class
javatest/.class : no such file or directory

If I manually remove the forward slash, it works:
/usr/bin/jar cvf ../test.jar javatest.class javatest$foo.class
added manifest
adding: javatest.class(in = 426) (out= 277)(deflated 34%)

Is this a known issue?  Is there a simple workaround?

thanks
-pk

[Matthew]

We were able to reproduce the problem, and we're currently looking to see exactly where this extraneous escaping is being done.

The workaround for the time being is to simply create a new project build command using the Build > Add New Build tool… menu item. Attached is a screenshot of how I filled out the first page of the build tool wizard. On the 3rd and final page for the "Run from directory" setting your can use %rp (for Project path).

[pkusbel]

Thanks Matthew.  Question for your workaround:  will that new tool be added to the project such that it will show up automatically for other users?   Or will all of the guys on my team also have to manually create the new tool themselves as well when they open the project?

[Matthew]

The new tool will go right into the project's .vpj file. (It's a per-project thing, not a per-user thing). As long as everyone's using the same .vpj, you're good.

[Matthew]

We found the culprit. This affects the vsbuild executable (which is the helper utility that actually runs your project's command line builds), so it is not something that we can address with a Slick-C hotfix. But the behavior will be corrected in the SlickEdit 2014 release this Spring.