Community
Participate
Working Groups
In a Java project, I have a Source and a Build directory. When I use the Open Resource menu to look at a non-Java file, the Open Resource window shows me both the copy in the Source directory(s) and also the one in the Build directory. I think the Build directory source should be filtered out, since it is more natural to want to edit the one in the Source directory(s) -- otherwise changes may be overwritten with the next edit to the Source file. Clearly when the source and build directories are the same then the result should not be filtered, but it should be filtered from the build directory when they are different.
This is happening off the Navigator view. We have deliberately left both resources in this view. Do you have a strong use case to support the exclusion of the build directory's version? Essentially we cannot make assumptions about how someone will want to handle these non-Java files. Sometimes they are the same in the source and build directories but sometimes some tool has been run on the source to make modifications and the build version is different. Therefore, it must be possible for people to see both.
'Build' comes before 'Source' (or 'bin' before 'src' depending on what you call it) with the result that the open resource will always show the build version first. Any modifications to this file will be lost during the next build, with the great potential for non-Java (which could include things like XML files and other configuration files) and be subsequently lost. Additionally, the build directory is also usually not kept in sync with CVS repositories which means that the changes are most likely to be lost. Note that it does not necessarily mean that the resource cannot be edited by direct navigation to the file in the build directory but it should not be the default (or visible) when viewed in the Open Resource tool, which 99%+ of the time will be to edit a file and changes should be permanent. The Java build process copies every non-Java file from the source directory to the build directory, so it will always be the case that a non-Java file will be present twice in both the source and build processes. Your argument that it may be desirable to modify a file in the particular case of it being modified by a non-Eclipse build process is valid, but sufficently unlikely to make the preferable option to not make it the default. I don't understand the comment: re 'Navigator View' -- it has nothing to do with the view directly; I raised this bug against the 'Open Resource' menu item which is visible from other perspectives, such as the Java perspective.
Am reassigning to Simon as we talked about this bug last week. Simon, do you have any comments to add?
We've lost changes due to this issue multiple times (it has bitten one of our developers frequently). We attempted to work around this issue by naming the output dir "zbin" and this works most of the time. We say most of the time because if you enter a resource name and then press the <home> key to enter more chars at the beginning, the match list reverse the order in which the hits are shown. We would like to see this bug fixed as lost changes can be very frustrating. I agree with Alex and think the best solution is to filter out the build directories from the open resource tool.
The workbench has no idea there is such a thing as a "source" and "build" directories - that's all JDT stuff. All it knows is the name you typed in matches two resources in different folders. Nevertheless, the dialog results need to be improved so as to avoid (or minimize) editing the wrong resource. If you have suggestions, please annotate this bug report. My recommendation is to make use of IResource.isDerived() (maybe also isPhantom () and isTeamPrivateMember()). This indicates the resource was created using an other resource. So we could filter these out, or better yet place them at the bottom of the list so they are still accessible.
In ANY case, the default behavior if the user just types a file name and hits enter should NEVER be to open a derived file when a non-derived file with the same name is present in the list of hits. That is, I don't care so much whether the derived stuff is filtered out or not, just so long as the non- derived one is listed first [regardless of how I've named my output directory or what sequence of keystrokes I've used to compose a pattern string]. If both the filtered and non-filtered views seem to be quite useful, perhaps a checkbox should be added to the Open Resource dialog to toggle the filtering. If build and src directories are the same, then there is no derived file, because no copy takes place, so this issue has no bearing.
I'd go further than that, and not show them if they are derived. After all, there's not much point in editing a derived resource if they then may be overwritten at a later stage. What you might like to do is have a checkbox (or preferences tab) which says 'Show derived resources in open resource window' which is initially unchecked; that way, you'll only see the one non-derived resource when you open the window, but it's an option that can be changed afterwards. Note that browsing through the navigator view should let you see any resources, whether derived or not, and as such there probably isn't any reason for showing derived resources in the open resource window. Of course, this assumes that everything in the build directory (compiled Java files and non-Java copied files) are marked as derived ;-)
I'm not sure this should be classified as an enhancement over a minor bug. As raised in the first instance (and repeated in comment 4 and comment 6 above) this has caused work to be lost when the 'wrong' file was edited.
I've just spent the last couple of hours wondering why my changes haven't made it into a piece of code that I've tested, only to find that this bug is still kicking around in M7. It's not an ehanchement, it's a real bug and it's causing me grief -- the suggestion to filter derived resources from the 'Open Resource' view as suggested in comment #5 would seem like an excellent fix to this problem. (on the assumption that the JDT is correctly marking copied resources from the 'Source' to 'Build' directories as derived ... but that could be a subject of another bug. Adding a checkbox to the 'Open resource' page to allow derived resources to be hidden/shown may be a possibility, but I don't see the need for ever editing a derived resource ...
Created attachment 9195 [details] Fixes bug by ignoring derived resources Checked patch against M7, works by filtering resources from build directories :-)
Created attachment 9196 [details] Patch Jar file implementing patch, can be added to Eclipse startup CP to fix problem Compiled single file with patch, can insert it into existing builds by amending org.eclipse.ui.ide_x.x.x/plugin.xml file as follows: <runtime> <library name="patch.jar"> <export name="*"/> <packages prefixes="org.eclipse.ui"/> </library> <library name="ide.jar"> <export name="*"/> <packages prefixes="org.eclipse.ui"/> </library> </runtime> Provided for those working with WSAD 5.0/5.1 or Eclipse 2.1 for whom the patch isn't going to make it in.
This issue is so frustrating, I can't believe that it does not annoy the Eclipse developers themselves! :) Please, a tick box, or filter option at the very least to allow resources in the build output to be excluded from view. I have had many people confused by this, editing a file open from this dialog and not thinking about exactly where it is they are editing the file.
What's worse, I fixed the bug in time for the 3.0 stream, but it didn't make it in ... The JAR file attached fixes the bug for the 2.1 release; if you're interested, I can mail a patch for the 3.0 release (or attach one to this bug)
Still applies in 3.0, still causes data loss when you open up the wrong resource and edit that instead. Updated bug version to apply to 3.0 in the hope this will get it fixed sooner.
Patch released. Sorry this didn't make it into 3.0. I debated adding a toggle to the UI, but unless someone complains I don't think it's worth the additional complexity.
*** Bug 34905 has been marked as a duplicate of this bug. ***
Verified in 200411022000
