Community
Participate
Working Groups
I20030206 - create a normal Java project - create a folder and link the folder to an existing workspace. Observe: the link is rendered as an empty package and a lot of ghost folders are rendered as well. - delete the link folder/package Observe: this also deletes folders from the source folder as well (the .metadata directory and sometimes projects as well), resulting in Loss of DATA. Note that the dialog that pops up states that only the link will be removed from the workspace.
i cannot link a folder to an existing workspace (the dialog will not allow me) did you mean _any_ workspace or the workspace that the project is in? (i cannot do either, but would help to know)
not, true - i can link a folder in workspace to A to workspace B (there's a warning in the dialog)
btw, it's a very strange idea to link a folder inside 1 workspace to point to a whole workspace
That's correct, but the problem results form the folder names containing a '.'. See bug 31383 which might be helpful here as well.
could not reproduce deleting projects (.metadata does seem to be gone) whatever causes it - it's unlikely us; we call ISourceManipulation::delete(false, pm) on the IPackageFragment
Can you provide exact steps to reproduce ? What is the exact classpath of the normal Java project ? How is the linked folder playing on the build path ? Is the link targeting the root dir of a workspace ?
You can use the setup described in bug 31383. When you delete link the whole contents of link gets deleted. But I suspect that happens only to folders that have a . in its name.
There are too many ramifications if we implement logical operations on Java elements when links are in the game. At the platform level, links are lightweight. At our level they don't exist as links, just as folders. If we were to change this, we would not be able to preserve subpackages (or nested source roots) when unlinking a folder. At the resource level, this is what you want, but at the Java model level this would be a big change. Also, what about copying a linked package, are we updating all children package statement to reflect the new link name (what if others still share sources). At this point in the game, this is way to risky to address. We will address short-term data loss by refusing to perform such operations on linked resources alltogether. UI should only perform a resource operation once it has detected a linked resource is underneath. Moving to UI for further action.
Philippe, why can't you detect the case that the underlying resource is a link and only delete the "link" in this case. If we add that logical we have to keep it in sync with what the Java model is doing, which, as you pointed out, might change in the future. Can you please comment on this.
The model is currently agnostic about links, and clearly doesn't support them for these operations. If we did act on the link itself, it would likely become inconsistent on the Java model side (wouldn't preserve subpackages any longer). Also the delta computation wouldn't be trivial looking at our code, doable but scary to change at this point. Disabling our code in case a link scenario is detected is the most we can do. For now, given you special case links already (ask confirmation to user), it should only do a resource action, not an (unsupported) Java model action. We are only talking about RC1 here. Post 2.1 we may want to leverage these operations into the model.
OK, that makes sense. Adam, how much work is it to detect this case and to call the corresponding method on IResource.
well, this would be nothing else than one more workaround for missing functionality/bugs
This is correct, but as Philippe pointed out they can't fix it for 2.1 but are willing to do so for 2.2. So I think we should add the work around and move the PR to Core after we added it.
no probs, agreed to put a question/warning dialog that subpackages will be deleted too i mean, given a package strucitre a a.b a.b.c where a is a linked folder, deleting package a will cause the whole subtree of foilders underneath to be unlinked, which will remove all 3 packages from the workspace. i will put a warning saying that this will happen
workaround added - you get information in the dialog and the package or cu is unlinked (in the case of deleting a default package (which is unsupported by jcore but worked around in the ui) all cus are unlinked) moving to core for further action
Post 2.1
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
