Community
Participate
Working Groups
When using path variables like ${container_path} a leading slash ('/') is always generated. Example: /Thunderbird/Prod/de/sparkasseninformatik/thunderbird Expected: Thunderbird/Prod/de/sparkasseninformatik/thunderbird (without leading slash) When using batch scripts, this is an ugly problem. BTW: IntelliJs IDEA does not produce such slashes.
some more information: The same happens with the variables $(project_path) and $(resource_path). I'm using the default workspace within the Eclipse installation directory (<Eclipse_inst_dir>\workspace) and the project uses the default location i.e. <Eclipse_inst_dir>\workspace\Thunderbird (Thunderbird is the projectname) BTW: why do the variables $(project_path), $(container_path) and $(resource_path) generate slashes ('/) insted of backslashes ('\') at the Windows platform ? The variables $(workspace_loc), $(project_loc), $(container_loc) and $(resource_loc) work fine.
Needs investigation
Jared, please see if these problems still exist with the variables re-work that you did.
The variables still behave as described. The paths that are output from the path variables are in the platform independent format Eclipse uses for workspace-relative paths. I'm mildly hesitant to change this behavior because there could be users with tools that depend on the paths to behave this way.
I've posted to the newsgroup asking if anyone is relying on the current format. If there are no positive responses, my inclination is to change this as requested.
Note that the eclipse platform distingues carefully between "paths" and "locations". Paths are always workspace or project relative, never have a device, and always use forward slash. Paths in this context describe where resources are found in the workspace, regardless of their location on disk. Locations always refer to places in the file system. These are always absolute, contain a device if applicable, and use the underlying OS path separator ('\' in windows). This is an important distinction, and they are not generally interchangeable. For example: d:\eclipse -> eclipse install diretory d:\foo -> location of project P1. d:\foo\abc.txt -> File inside project P1. The location of P1 is d:\foo, the workspace path of P1 is /P1. The location of abc.txt is d:\foo\abc.txt, the path is /P1/abc.txt. I suspect this is why the external tools have two different variables, ${resource_path) and $(resource_loc). Unless you're using eclipse-specific ant tasks, you probably just want the location, and don't care about the paths.
Right. But are Eclipse "paths" "/../text.txt" really useful outside Eclipse? I don't think so. Outside Eclipse, slashes are generally platform dependent. On *nix, for example, a leading forward slash is a device name equivalent to "C:\" on Win32.
Right, most ant users (probably including Bernhard) are only interested in "locations". They can simply use resource_loc and project_loc instead of resource_path and project_path. If you're using Eclipse ant tasks, such as refresh local, you need to use "paths". There is also an Eclipse ant task (eclipse.convertPath) for converting resource paths to locations, and vice-versa. This probably just needs to be better documented.
Bernhard, can you use the *_loc variables or do you require workspace-relative, OS-dependant paths? That is, what is your use case?
I'm using the parameters of the external Tool menu in some shell-scripts (DOS-SHELL / cmd.exe). These scripts expects relative paths, which are DOS conform. Therefor Unix-like paths or absolute paths are not usable. Perhaps there should be an option in order to specify how these parameters are resolved: Unix-style or DOS-style.
Bernhard, once again, these paths do not describe locations in the file system. They are a symbolic paths used to find resources in the workspace tree. They might not correspond to the paths of the resources in the file system. If you want relative paths, what do you expect them to be relative to? The workspace directory (the one specified by -data)? The project location? The current working directory? Can't the shell scripts handle the absolute paths supplied by resource_loc and project_loc?
OK, perhaps I do not know enough about the special features of Eclipse / advanced filesystems like symbolic links. I'm working with Windows NT 4.0, SP6a. My workspace is hierarchically organized, i.e. all projects are located under the workspace root (as specified with the -data option). My script is executed in the folder of the workspace root. It concats an "viewpath" (a path that point to a location in a SCM-System, defined by an environment variable) with an relative path (provided by Eclipse). My current workaround is to use a small C-program in order to reformat the relative path to a valid DOS-Path.
If it's any help, the ${workspace_loc} parameter expands to the workspace location. If you remove ${workspace_loc}/ from the beginning of a ${resource_loc}, you'll get the path you're looking for. I don't know if ant has any string manipulation tasks that can help you do this. In your case ${resource_path} happened to work because you stored all your projects in the default location, but this won't be true in general if you have projects in non-default locations or linked resources.
I don't think Ant ships with any string manipulation tasks, but they could be out there as add-ons... or it would be easy to write them. We *could* provide variables that would expand to workspace-relative, OS-valid paths, but I'm hesitant to add too many variables that aren't generally useful. Bernhard, external tools makes it relatively simple to define your own variables in a plug-in. If you're interested in this approach, take a look at the variable definitions in the org.eclipse.ui.externaltools plugin.xml file (Ctrl+F and search for resource_loc to jump to it). For the implementation of a "variable expander", take a look at the class ResourceExpander. If you're not concerned about API rules (which you're probably not if it's just for your use), you can just subclass ResourceExpander and override the getPath(...) method to return the path in the format you want.
We won't be making any code changes for this bug for 2.1. Marking as LATER as we might want to add this to 2.2.
*** Bug 43413 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
