Community
Participate
Working Groups
Build id: 200211051258 The Ant runner sets the basedir property (${basedir} in ant scripts) to the working directory and not the directory of the ant script like normal ant does. i.e. for 'c:/foo/build/bar.xml' run with a working directory of 'c:/foo' basedir should be 'c:/foo/build' But instead it is being set to 'c:/foo' This happens when using ant runner 'variables like so: Location: ${workspace_loc:/foo/build/bar.xml} Working Dir: ${workspace_loc:/foo} I haven't tried it with absolute paths
Maybe I am missing the obvious here but what would the meaning of setting the working directory be for an Ant build?
I was only explicitly setting the working dir to illustrate the bug. If left unset, the working dir defaults to some other value (I think it was the eclipse working dir?), and basedir ended up being that value. Also, as a workaround, I _had_ to set the working dir to the location of the script for basedir to be set correctly. You are correct in that that working dir should be irrelevant to running an ant script, but the prescence of this bug was causing it to have an effect. When I created this bug, basedir was not getting set correctly if I left the working dir unset. However, in build 200211151436, it seems that if I leave working dir unset, basedir does get set correctly, but if I _do_ set working dir, then basedir incorrectly gets set to that value (basedir should ALWAYS be the location of the script).
So as a user, working directory specification should not be allowed for an ant script?
I'm not sure thats right either. In CLI ant, you can have different values for ${basedir} and System.getProperty("user.dir") (via java script, or java code in a custom task) So, a user should probably be allowed to set the working dir for a script execution, but doing so should not affect the value of basedir.
Thanks for the explanation. The unfortunate part of setting system properties is the currently Ant can only be run in the same VM as eclipse. Changing the user.dir could cause all sorts of problems. Maybe this can only be a feature when Ant can be run in a separate VM (bug 24129)?
Unfortunately it goes further than just the system property - java.io.File path resolution uses the JVMs working directory for relative paths =( I guess so long as basedir is always set correctly, there is not much need for being able to change working directory for a script. A well written script should not be dependent on what directory it is run from anyway. Originally, I wasn't so much concerned with setting the working directory, just having a correct value for ${basedir}, as all paths in my scripts end up being constructed relative to basedir. If you aren't running ANT scripts in a new JVM, what effect does the working directory field have?
Currently setting the working directory sets the basedir.
Ok, thats confusing, or at least inconsistent with the way ANT does things, and should probably be changed. ${basedir} exists so that scripts don't have to rely on working directory, so setting basedir to the value of the working directory seems wrong. The field should probably be removed untill you add a way to run an ant script in a new JVM.
Likely should be done when reworking the launch configuration tabs to be ant specific and to handle launching in a separate VM.
*** Bug 28802 has been marked as a duplicate of this bug. ***
Our current plan is to rename the text field "Base Directory". We have a set of users who are relying on the fact that they can set the base directory from the UI.
Fixed in AntMainTab and ExternalToolsMainTab Please verify (DarinW).
Verified.
