Bugzilla – Full Text Bug Listing
| Summary: | Need to perform a validateEdit() before setting encoding | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Jess Garms <jgarms> | ||||||
| Component: | APT | Assignee: | Walter Harley <eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | eclipse, konstantin | ||||||
| Version: | 3.3 | ||||||||
| Target Milestone: | 3.3.1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Here is a related platform bug (fixed in 3.3) that has a new validateEdit() API that we can use: https://bugs.eclipse.org/bugs/show_bug.cgi?id=160905 This behavior is present in 3.2 as well, correct? (If this is a regression we should perhaps push to get it into 3.3 even though we are already in RC3 and changes are extremely unpopular. If we can wait till 3.3.1, that's easier.) Correct: this behavior was present in 3.2. Created attachment 69640 [details]
Patch for calling validateEdit when setting encoding
Note: underlying all this is the basic problem that char encoding settings for generated files are stored in a file that is under source control. This is a fundamental Eclipse problem. In other words, even if we call validateEdit() here, the best that's going to happen is that a bunch of prefs files will be checked out, and eventually checked back in, containing data about generated files that should never have been version controlled in the first place. The real fix is to better tie encoding settings to the files they modify. Released patch to HEAD and to 3.3.1 Created attachment 80493 [details]
Patch for 3.2.2
Attached patch is a workaround for version 3.2.2.
(In reply to comment #5) > Note: underlying all this is the basic problem that char encoding settings for > generated files are stored in a file that is under source control. This has been entered as bug 207510. |
If a project is checked into a read-only source control system like perforce or subversion, you get an exception like the following during annotation processing: org.eclipse.core.runtime.CoreException: File /wlwLabInventoryWar/.settings/org.eclipse.core.resources.prefs is read-only. at org.eclipse.core.internal.resources.ProjectPreferences$2.run(ProjectPreferences.java:556) at org.eclipse.core.internal.resources.ProjectPreferences.save(ProjectPreferences.java:577) at org.eclipse.core.internal.preferences.EclipsePreferences.flush(EclipsePreferences.java:352) at org.eclipse.core.internal.resources.ProjectPreferences.flush(ProjectPreferences.java:379) at org.eclipse.core.internal.preferences.EclipsePreferences.flush(EclipsePreferences.java:340) at org.eclipse.core.internal.resources.ProjectPreferences.flush(ProjectPreferences.java:379) at org.eclipse.core.internal.resources.CharsetManager.setCharsetFor(CharsetManager.java:281) at org.eclipse.core.internal.resources.File.setCharset(File.java:440) at org.eclipse.jdt.apt.core.internal.env.EncodedFileOutputStream.close(EncodedFileOutputStream.java:36) at sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:431) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:160) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:222) at java.io.PrintWriter.close(PrintWriter.java:287) at org.apache.beehive.netui.compiler.genmodel.GenStrutsApp.writeToFile(GenStrutsApp.java:358) Need to have a validateEdit() call on the resources.prefs file before setting the charset.