Community
Participate
Working Groups
When you create a new file/folder you have the option to 'link to a folder in the file system'. It would be very usefull to have a 'link to a resource in the workspace' options. This would be very usefull when you want to share resources between 2 or more projects like: ProjectA/FolderA ProjectB/FolderB (linked to FolderA) you can have this behaviour now but the physical location of the file is stored in the .project file, so it is useless for a team working with CVS. (Each user has to manually fix the .project file marking the file as an outgoing change).
(In reply to comment #0) > When you create a new file/folder you have the option to 'link to a folder in > the file system'. It would be very usefull to have a 'link to a resource in the > workspace' options. This option would be very useful. At least it would be great, if the path to the linked resource could be stored as a relative path.
This seems equivalent to defining a path variable that points to the workspace location (see Preferences > General > Workspace > Linked Resoruces), and then make all your linked resources relative to that variable (Click the "Variables" button when creating a linked resource).
*** Bug 144643 has been marked as a duplicate of this bug. ***
I would like to comment on #2. I don't think that this is equivalent because the path variable can point to the physical workspace root and not the ligical (resources) workspace root.
Description of the duplicated BUG 144643 may help - create a java project named test1 - create a java project named test2 - open properties dialog of the java project test2 - create a new source folder (java build path - Source - add folder) and click create new folder - advanced, activate checkbox "link to folder in file system" and select the source folder of project test1. - open the .project file of the project test2 and see the absolute path. This causes problem in merging changes from one project to another The problem with the variable that you need to redefine it when you change views of clearcase for example. We would like to define a linked folder in the same way as a classpath reference to another workspace project can be defined. Example: We have two projects in a workspace project_a and project_b. When creating a linked folder we would like to be able to choose either browse workspace (for relative path) or the entire hard drive (absolute path).
*** Bug 72940 has been marked as a duplicate of this bug. ***
Ok, Let's see if I follow this thing correctly: When one creates a linked folder, through, for example, the 'new folder' action within a 'Navigation' view, it triggers: - org.eclipse.ui.dialogs.WizardNewFolderMainPage#validateLinkedResource() which delegates the path validation to its linkedResourceGroup (an CreateLinkedResourceGroup widget dedicated to the specification of a linked file or folder target) - org.eclipse.ui.internal.ide.dialogs.CreateLinkedResourceGroup#validateLinkLocation() validates its path through the workspace. The WORKSPACE! It must have all the informations we need, right ? Like the absolute path of any project, candidate for the root of the linked 'relative path' folder we want to create. - org.eclipse.core.internal.resources.Workspace#validateLinkLocation() delegates the validation process to its LocationValidator (which implements the various path, URI, and name validation methods in the workspace API) - org.eclipse.core.internal.resources.LocationValidator#validateLinkLocation() tries to resolve the path through its PathVariableManager (which manages a collection of path variables and resolves paths containing a variable reference... and allows only a variable reference to appear as the first segment of a relative path) - org.eclipse.core.internal.resources.PathVariableManager#resolvePath() returns the path (like '../arelativepath') as is, since the first segment ('..') is not absolute and does not correspond to any classpath variables. So, then the LocationValidator finds out that the path returned is not absolute and returns a IResourceStatus.VARIABLE_NOT_DEFINED_WARNING message... Now, what if the PathVariableManager was able to interpret a ${project_path:another_project} variable like the ones we find in the launcher configurations ? That means the PathVariableManager would also allow for ${project_path:} variable to be a correct first segment, instantly replacing that variable with the absolute path of the specified project, allowing a relative path to be defined, relative to that absolute project path. The user would enter ${project_path:another_project}/../arelativepath If you fear for any side effect, maybe you could implement that new behaviour one level above the PathVariableManager, in the LocationValidator#validateLinkLocation() method. Any comment ? (Before I start overriding org.eclipse.core.internal.resources.PathVariableManager in my eclipse3.2 / 3.3M1 and see what happens ;) )
The best solution is likely to adopt the full-blown variable support used by the launch configuration dialog. This is defined in the org.eclipse.core.variables plugin. This would likely also require StringVariableSelectionDialog to be pushed down from org.eclipse.debug.ui into org.eclipse.ui.ide. The implementation in org.eclipse.core.resources would then consult IStringVariableManager in org.eclipse.core.variables rather than the existing PathVariableManager. Of course, for backwards compability those variables would still need to be supported.
Is there a way to include that evolution (described in comment #8) within the proposed items of http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html ? For example, could you consider that it is one of the evolutions necessary to solve bug #154097 ? ("Managing and sharing settings") It really comes down to solve the current impossibility to **share** an eclipse project without having to redefine something (here: 'Linked path variables') in order to make that shared project work...
Created attachment 48706 [details] Linked Folder Patch Project Plugin overriding PathVariableManager and IPathVariableManager in order to link a folder of a 'test1' project from 'test2' project Should be used with an 'Eclipse application' Laucher using a runtime workspace included in a second zipped attachment.
Created attachment 48707 [details] Linked Folder Patch Runtime Environment Runtime Environment for an 'Eclipse Application' launcher using the Linked Folder Patch Project attached in this page. See instructions comment #10
Just playing around, I have created a very small plugin project 'Linked Folder Patch Project' associated with a runtime environment in which 2 projects test and test2 have been created. test contains a folder 'a' with a file testa.txt You can create a linked folder within test2, called 'a', linked to 'test/a': it will be resolved as <OS absolute path of test>/a. Just : - unzip the 2 zip files, - import the Linked Folder into your workspace, - create an 'Eclipse Application' Laucher running the application 'org.eclipse.ui.ide.workbench' - Set the location of the Workspace data of this Launcher to <Full path of the Linked Folder Runtime Environment> - add to the program arguments of that laucher: -dev <Full path of Linked Folder project>/cls - Run and try to create a Linked Folder within test2, with 'test/a' as value It it just a quick test where I replace the first segment of the linked path ('test') with its full OSSystemPath. Obviously, the correct linked path should be {project:test}/a, hence the proposition of "the full-blown variable support used by the launch configuration dialog" described in comment #8. However, with my quick patch, I was not able to refer to a relative path **sibling to** my project directory, like test/../anotherdirectory: I must go back up one level (../) then add the sibling directory (anotherdirectory) But when LocationValidator tries to validate the IPath("test/../anotherdirectory"), that IPath is actually valued as "anotherdirectory", because when that Path is build, the canonicalize() function of org.eclipse.core.runtime.Path removes all occurrences of ".." segments from this path... So only "anotherdirectory" is resolved by the (modified) PathVariableManager... which obviously fails (the project 'test' is not there anymore to be replaced by its full OS path) I suppose the org.eclipse.core.variables plugin does support that scenario (I have not look it up yet) The point of that quick fix is to provide other curious eclipse users with a small project allowing them to experiment with this issue.
*** Bug 164064 has been marked as a duplicate of this bug. ***
*** Bug 182103 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > The problem with the variable that you need to redefine it when you change > views of clearcase for example. > We would like to define a linked folder in the same way as a classpath > reference to another workspace project can be defined. The comment Sherif Zaki made was driven by a PMR opened against RSA6 by our company. We still wait for the fix. We have 2 special situations where we need this: 1. We have gui projects where we code views for our own framework (gui elements). To work with them in the visual editor we have change the framework jars in the classpath so that the views can be displayed. So we defined another project named guidesign where we link the source folder of our gui projects and configure the claspath as mentioned above. The problem is that the path is stored as an absolute path. => All developers are forced to use the same location of the view (e.g. c:\ccstore\myviewforcomponent1.0\...). => For a following release we have a different view location (e.g. c:\ccstore\myviewforcomponent2.0\...). All design projects have to be changed. 2. We would like to use the clearcase remote client. Having the server process installed on a unix machine the view will have an additional path element named vobs (c:\ccstore\myviewforcomponent1.0\vobs\...). In this scenario it is not possible to work with remote views and local views at the same time in a project. These are limitations we would not have if the linked resource would be a relative path in the workspace.
*** Bug 29023 has been marked as a duplicate of this bug. ***
Hi, is there a plan to implement this enhancement? We had to make a cumbersome workaround to avoid storing the absolute paths in the .project, so it would be very much appreciated. Thanks.
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.
