Community
Participate
Working Groups
My current build process requires me to call ant with various directory paths set as "-D" parameters, which worked in F2. In F3, this is broken because of how variables are being treated. Quotes are being passed in around the expanded variable. Example (using F3): Buildfile: build.xml all: [echo] test.variable="/home/burner/.eclipse/testcase" BUILD SUCCESSFUL Total time: 1 second And here's what I expect (and what F2 did for me): Buildfile: build.xml all: [echo] test.variable=/home/burner/.eclipse/testcase BUILD SUCCESSFUL Total time: 2 seconds Here is how my external tool is setup (as copied from the external tools configuration window): Location: /usr/bin/ant Arguments: -Dtest.variable=${project_loc:/testcase} Directory: ${project_loc} And here is the example build.xml file I used to get this result: <?xml version="1.0"?> <project name="test" default="all"> <target name="all"> <echo message="test.variable=${test.variable}"/> </target> </project> I don't know a decent way around this, besides not using the variables and hand coding the paths to my projects (which I am rather loathe to do in the long run). mike
Tried with build 20020618 and I cannot reproduce using Windows. Will try on Linux. Here is what I get on Windows XP Pro: all: [echo] test.variable=C:\eclipse\test\antworkspace\Test
Could reproduce with F3 and 20020618 under Linux. I do not believe the problem is in org.eclipse.ant.core because the external tool in this case is not an Ant script but the Ant launcher that ships with a binary distribution of Ant. Needs more investigation to see what has changed between F2 and F3 in this area.
I've just installed F2 (20020602) and it also gives the location using quotes - so, I see no differences between F2 and F3. Could you try again and make sure F2 gives you the location without the quotes? Thanks.
I have just downloaded F2 (20020602) again, and unzipped it to a new directory and created a new workspace. I created a new simple project (with the wizard) called "testcase", in the project I created a build.xml file with the code copy/pasted from this page. I then created a new "external tool" entry with the following details: Location: /usr/bin/ant Arguments: -Dtest.variable=${project_loc:/testcase} Directory: ${project_loc} I got this output: Buildfile: build.xml all: [echo] test.variable=/home/burner/eclipse/F2/eclipse/workspace/testcase BUILD SUCCESSFUL Total time: 2 seconds I'll shortly post my results with a newly download and unzipped F3...
I just followed the same steps I just described with F3 (20020612), and get this result: Buildfile: build.xml all: [echo] test.variable="/home/burner/eclipse/F3/eclipse/workspace/testcase" BUILD SUCCESSFUL Total time: 2 seconds
I suppose I should provide some more details of the system I'm running on: Debian sid/unstable (I can provide library version details if necessary) Sun's JDK1.4.0 java -version: java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) Ant version 1.5beta1 /usr/bin/ant -version: Apache Ant version 1.5Beta1 compiled on May 26 2002 mike
It seems that the UI has done some work in this area (adding quotes to the working dir). Moving to Platform UI for comments.
The quotes were added to handle paths that include spaces. Unfortunately we did not test on Linux. Investigating further...
Here's a shell script that also exemplifies the problem I just cooked up to focus on what F3 is doing differently (and pull out any possible ant : #!/bin/sh echo _=$_ echo 0=$0 echo 1=$1 [ -f "$1" ] && echo File exists || echo File does not exist I created test.sh in my testcase project, and create a new External Tool with the following properties: Location: ${workspace_loc:/testcase/test.sh} Arguments: ${resource_loc} Directory: ${workspace_loc:/testcase} I run this by clicking on the test.sh file in the testcase project and running the "test" external tool. And when I run this in F3, it says: _=/bin/sh 0=/home/burner/.eclipse/testcase/test.sh 1="/home/burner/.eclipse/testcase/test.sh" File does not exist In F2, it says: _=/bin/sh 0=/home/burner/.eclipse/testcase/test.sh 1=/home/burner/.eclipse/testcase/test.sh File exists mike
There are three potential fix options: 1) Check to see if a path has spaces, and only enclose in quotes if it does. This will eliminate regression, and users will still be able to use paths with spaces in Windows, but will not be able to successfully use paths with spaces in Linux. This will solve Micheal's problem with minimal effort. 2) Put platform-specific code in org.eclipse.ui.externaltools. Use quotes to enclose paths in Windows, and use the proper method to handle paths with spaces for other OSs. This would solve the problem for users of both platforms, but in my opinion is a little more risky and would require lots of testing for different platforms. This could overlap with option 1, but that would be a lot of work. 3) Ask core to provide API to pass AntRunner the arguments as an array of Strings, instead of as a single String of arguments seperated by spaces. Thsi would be the most complete solution, but would require non-trivial changes to our code. Recommended as post-2.0 solution.
Ryan, about #3 - in the current test case AntRunner is not being used. The external tool is /usr/bin/ant and not the script itself.
Marked for F4 since this is a regression. Option 1 seems the safest. Also note that it's better to use the Runtime.exec(String[], ...) variants rather than exec(String, ...). The reason is that the String variants parse the string into arguments using StringTokenizer, which does not understand quotes. It merely tokenizes based on white space. So, Runtime.exec("someProg \"the parameter\"") ends up being equivalent to Runtime.exec(new String[] {"someProg", "\"the", "parameters\""}). Now, depending on how the natives are written, they may get glued back together properly, but they might not.
Need a proposed fix before seeking approval.
Suggested fix: Change DefaultRunnerContext as shown (adding call to hasSpace(String)), and add method hasSpace(String) as shown below. Changing our calls to Runtime.exec(...) to use an array of Strings instead of a single string would require non-trivial changes to DefaultRunnerContext [see expandVariables(...), expandVariable(...)]. Since regression is avoided with the fix below, I'm not convinced that switching to Runtime.exec(String[], ...) is a good idea at this point. /** * Helper method to add the given variable string to the given * string buffer if the string is not null. Adds enclosing quotation * marks if addQuotes is true. * * @param var the variable string to be added * @param buf the string buffer to which the string will be added * @parman addQuotes whether or not to add enclosing quotation marks */ private void appendVariable(String var, StringBuffer buf, boolean addQuotes) { if (var != null) { if (addQuotes && hasSpace(var)) buf.append("\""); //$NON-NLS-1$ buf.append(var); if (addQuotes && hasSpace(var)) buf.append("\""); //$NON-NLS-1$ } } /** * Returns whether or not the given string contains at least one space. * * @return true if the given string contains at least one space, false otherwise */ private boolean hasSpace(String var) { int index = var.indexOf(' '); if (index >= 0) return true; else return false; }
Alternate solution: Never automatically add quotes. The user can add quotes to the commnad line arguments manually if they wish to use quotes. Change required: in DefaultRunnerContext.getExpandedArguments(), change call to expandVariables (String, boolean) to use false instead of true. if (expandedArguments == null) expandedArguments = expandVariables(tool.getArguments(), false);
No to the last alternative (i.e letting user add quotes). It's the responsibility of the external tools plugin to format the paths in such a way that is acceptable for the platform.
I got the same results as Rodrigo on WIndows: no quotes [echo] test.variable=D:\0619i\eclipse\workspace\testcase
Approved to fix: quotes will only be added when there is a space in the value. This will work fine on Windows for both variables with spaces and those without. On Linux, it will work for variables without spaces, but the quotes will still be taken literally when added for variables with spaces. Added bug 20797 to revisit this post 2.0.
The limitation on Linux needs to be documented in the readme.
In the readme, should mention that a workaround on Linux for variables with spaces is for the script to strip off quotes.
Ryan implemented the suggested code changes Checked by Simon and Tod
