Bug 190268 - Need to perform a validateEdit() before setting encoding
Summary: Need to perform a validateEdit() before setting encoding
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: APT (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3.1   Edit
Assignee: Walter Harley CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-31 12:29 EDT by Jess Garms CLA
Modified: 2007-10-31 01:45 EDT (History)
2 users (show)

See Also:

Attachments
Patch for calling validateEdit when setting encoding (1.75 KB, patch)
2007-05-31 19:14 EDT, Jess Garms CLA 		no flags Details | Diff
Patch for 3.2.2 (2.48 KB, patch)
2007-10-16 15:50 EDT, Walter Harley CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jess Garms CLA 2007-05-31 12:29:20 EDT 
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.
Comment 1 Jess Garms CLA 2007-05-31 14:49:14 EDT 
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
Comment 2 Walter Harley CLA 2007-05-31 15:13:49 EDT 
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.)
Comment 3 Jess Garms CLA 2007-05-31 15:16:40 EDT 
Correct: this behavior was present in 3.2.
Comment 4 Jess Garms CLA 2007-05-31 19:14:10 EDT 
Created attachment 69640 [details]
Patch for calling validateEdit when setting encoding
Comment 5 Walter Harley CLA 2007-05-31 20:04:15 EDT 
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.
Comment 6 Walter Harley CLA 2007-07-20 19:04:41 EDT 
Released patch to HEAD and to 3.3.1
Comment 7 Walter Harley CLA 2007-10-16 15:50:57 EDT 
Created attachment 80493 [details]
Patch for 3.2.2

Attached patch is a workaround for version 3.2.2.
Comment 8 Walter Harley CLA 2007-10-31 01:45:04 EDT 
(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.