Community
Participate
Working Groups
In the 3.2 release the option "External Tools/Common/Shared file" isn't working (for external programs not ant builds). It was working in previous 3.1 versions and until 3.2M2 (haven't tested other milestones). If a shared file location is chosen, the Apply can be clicked but nothing happens and when clicking on Close it asks to save the changes and there again nothing happens if Yes is chosen. More than that the .launch files created in projects with previous versions of eclipse are no longer seen in the list of External Tools when the projects are opened in 3.2 release. The only external tools still usable are those found in the local working space. The project's specific external tools can't be seen and neither created. On the launching console (from where eclipse is executed) there is no exception listed.
I could identify more precisely what's happening. For the creation of new external tools, the project should be deleted from the workspace and recreated in the workspace if this was a 3.1 workspace. After that the creation of new external tools works. There remains one problem: Existent .launch files (found in the project) are not seen in some cases. If the file is a synmbolic link to a file found in another user's folder (created with the other user's credentials) then it does not appear as an external tool when importing/creating the project from an existent source. If the symbolic link is replaced instead with the file then everything is working. This behaviour wasn't found in the previous versions. As some team development tools on linux make use of such symbolic links when sharing projects (aegis for instance), keeping symbolic links to files that are not modified, this new behaviour makes difficult the use of shared (by project) external tools with such team managed projects.
Moving to debug as this is common support within Eclipse
From testing I found that: If you bring a symbolic link into your workspace, which you then try to import a project from, it appears as though the link location is superimposed on the actual location of the file. In this context it means that when we try to create the launch configuration from its shared file it fails because the location given to it does not exist. Consider the following example: 1. you have a project somewhere (on another computer, in another folder, whatever) with a path /a/b/c/project, that contains a shared launch configuration lc (with path /a/b/c/project/lc). 2. create a symbolic link to the project in your current workspace, resulting in a path like /workspace/link 3. do an 'import existing project into workspace' and select the symbolic link (link from step 2), uncheck copy project into workspace. 4. when we try to create the shared launch configuration it fails because the returned location does not exist. More specifically, when we respond to the .launch file added resource delta, and we ask for the location of the file (using IFile#getLocation) and we are returned a location that does not exist, in this case the location is /workspace/link/lc, and not the correct location which is /a/b/c/project/lc. This seems like a Resources issue, as we are asking an IFile for its location, which is not correct when returned. Sending over to Platform Resources for comment.
Another example of .launch problems when symbolic links are found somewhere in the path: Take a project folder from the workspace and move it in a different folder. Create a symbolic link in the workspace folder with exactly the project's initial name and point it to the new project's folder. Theoretically this should behave as if the project was still in the workspace. This works without problems except the .launch files which are no longer seen (even if they are files and not symbolic links). This results in problems to create a new Builder in Project Properties. Clicking on New Builder... does just nothing. The only builder that works is the default Java Builder.
Symbolic links in the file system are opaque from the resources plugin's point of view - it doesn't know or care whether a given path is a symbolic link. If you have a link /workspace/link to location /a/b/c/project, then /workspace/link/lc is equivalent to /a/b/c/project/lc - it does exist, and if you ask the file system for the contents of the file at that location, it will resolve the symbolic link and give you the real file contents.
We end up using IWorkspaceRoot.findFilesForLocation(path), where the path contains the "linked" path. This seems to return "no" locations. Does this API work with "linked" paths? I.e. we pass in "/workspace/link/lc".
Ugh, my Linux box keeps freezing whenever I try to debug this. I'll have to defer investigating until I have more time. As for your question, findFilesForLocation should work based on the resource location you see in the Resource property page. I.e., if you pass in a location as it appears on that page, findFilesForLocation should return the corresponding resource.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
