Community
Participate
Working Groups
Build Identifier: 20100917-0705 It would be great if instead of telling you at the end of modifying a 100 classpath entries and clicking ok and then ignoring all those changes it would either remind you up front or give you the option to overwrite. Reproducible: Always
Can you give clear steps to reproduce?
Why is your .classpath file read-only?
The version control system I work with keeps the files readonly on retrieval - stupid I know. Anyway I always seem to forget to make the classpath non-readonly before using the project properties java build path and spending a bunch of time modifying it only to have eclipse discard my changes when I hit save as the file is readonly. Steps to repro: 1. Make your .classpath file readonly 2. Open your eclipse project 3. Project->Properties->Java Build Path->Remove an entry->Ok Error Dialog: 'Setting build path' has encountered a problem. File projectname/.classpath is read-only.
*** Bug 368108 has been marked as a duplicate of this bug. ***
This works if the team provider implements validateEdit(...) correctly. For example, when using watch/edit mode in CVS, the team provider makes the file writable. Now, for the case when there is no team provider (i.e. file not shared), validateEdit(...) asks the user, but that only happens if the client provided a context. Currently JDT Core calls validate edit with a 'null' context (see e.g. JavaProject.setSharedProperty(String, String). JDT Core needs to check whether they have a context (e.g. a shell) and if not, whether it makes sense to allow passing such a context by the client.
Marking as minor/P5 since 1. For shared files, the Team Provider should deal with this. 2. Users should not mark the .classpath file read-only themselves.
(In reply to comment #3) > The version control system I work with keeps the files readonly on retrieval - > stupid I know. Please file a bug against the provide of your Team plug-in.
The problem is that I am not using the perforce team provider or managing the revision control via eclipse. I use the tools provided by the version control vendor and I don't want to be forced to use an eclipse plugin to manage the revision control. Ideally I wouldn't be forced to use this implementation of a rcs where the files are marked readonly but I don't have that option. But let's extend the example out. Let's say I create a project, commit to my revision control system, and then get the source, zip and distribute out to the internet. The files will be readonly and anyone who loads this project into eclipse isn't going to have the rcs plugin and if they modify the classpath via the ui then they will encounter the same problem. I agree that the problem isn't major but if the fix is easy then if you'd consider normal priority I'd appreciate it.
> I agree that the problem isn't major but if the fix is easy It depends whether JDT Core already has a context somewhere. If not, new APIs need to be define, so that it can be provided. > then if you'd consider normal priority I'd appreciate it. Sure.
> It depends whether JDT Core already has a context somewhere. If not, new APIs > need to be define, so that it can be provided. JDT Core doesn't have a context, but bug 160905 added a generic IWorkspace.VALIDATE_PROMPT. Fixed in master with commit ec0896f6be6c41a0353321bffc1f242fe4e5e1b4.
(In reply to comment #10) > > It depends whether JDT Core already has a context somewhere. If not, new APIs > > need to be define, so that it can be provided. > > JDT Core doesn't have a context, but bug 160905 added a generic > IWorkspace.VALIDATE_PROMPT. > > Fixed in master with commit ec0896f6be6c41a0353321bffc1f242fe4e5e1b4. Nice!
This looks good, mostly. However, on Linux I still succeed to get the project into an inconsistent state: a) mark .classpath as readonly (chmod 444 .classpath) b) change the JRE on the projects classpath (using the prj. pref. UI) c) get a dialog asking whether .classpath should be made writable: GOOD! d) answer "No" e) observe the error dialog mentioned in comment 3 f) observe that the package explorer has (most the time(?)) already updated the "JRE System Library" whereas the content of .classpath has not been changed g) after an unsuccessful attempt to change JRE from 1.5 to 1.7 the compiler actually uses the 1.7 JRE as tested by referring to type AutoCloseable: Initially (using 1.5): error After unsuccessful attempt to change JRE to 1.7: no error Is this a known limitation?
I don't think this a known limitation. Could be fixed in a separate bug if somebody cared enough. This is not a new problem and requires a malicious user. The call to validateEdit should be pulled to the beginning of SetClasspathOperation#executeOperation(), guarded with this.canChangeResources and the other checks on rscFile in JavaProject#setSharedProperty(..), and the operation should throw a JME if the validation failed.
