Community
Participate
Working Groups
Build id: I20090113-0918 1. Fresh install. 2. Create a new PDE project. 3. Change Workspace file encoding to ISO 8859-0-1 Gets Project Warning: "The default encoding of 'MacRoman' does not match the project specific encoding of 'ISO-8859-1'" ??? 5. Change *Project* encoding to 'MacRoman' Note: MacRoman does not appear in list, you have to type it in manually. Message goes away. 6. Change *Project" setting to ISO 8859-0-1 Same message as above. I'm also certain this showed up in latest integration build.
See http://eclipsesource.com/blogs/2009/01/09/tip-encoding-issues-with-plug-ins/ and bug 155015. This new feature is here to warn you whenever the encoding set at project level isn't equal to the encoding set at project level *and* no specific clause (javacDefaultEncoding) has been added yet to your build.properties
OK, I'm not being convinced that this is a feature. :) I see it as an expediency, in that it makes more obvious a bunch of stuff that is broken. Or I'm just hopelessly confused and need to start drinking coffee again. "the encoding set at project level isn't equal to the encoding set at project level" Huh? :D Assuming you mean "default encoding" for one of these? But apparently (see below) we really aren't talking about the default encoding at all -- we're referring to the VM setting? At minimum, then, the message should change to something like: "The system encoding of 'MacRoman' does not match the project specific encoding of 'ISO-8859-1'". But this is wrong as well, because I haven't set a project specific encoding! So shouldn't the message really say something like: "The system encoding of 'MacRoman' does not match the **default** project specific encoding of 'ISO-8859-1'" ? Still confusing, but at least more accurate? There should also be some kind of message that makes it clear that this is a PDE build issue. "The system encoding of 'MacRoman' does not match the **default** project specific encoding of 'ISO-8859-1' PDE Build does not respect the configured default encoding." This is an important issue for those of us who use editors that require foreign character sets -- OpenArchitectureWare which is transitioning into Eclipse Project (GMT) -- uses ISO-8859-1. So my default on a Mac is ISO-8859-1. However, you are going to end up with cases of UTF, etc. (Question, does PDE build respect default file encoding determined from content, i.e. XML UTF?) I have over 25 separate projects so this becomes a maintenance issue and I simply can't wrap my head around why it needs to be. Now, in a comment from "zx" I get "@Kai, yap… this setting is per-plugin. The ideal solution here would be for PDE Build to be workspace aware but that’s going down another rabbit hole" OK, the PDE build *isn't* workspace aware?! This certainly violates the principal of least surprise in a big way. I'm gathering that this all is part of the continuing challenge that PDE build remains pretty orthogonal to workspace build. In this context, this warning seems to push what is a PDE build issue and turn it into a user issue. Finally, there is the issue of wether the PDE build, if it indeed cannot use the workspace setting for a deep reason, then why does it use the system specific one? The vast majority of plugin developers are developing cross-platform. I don't think there is any really good reason to use MacRoman as the default encoding. I suspect that the situation is similar on the other platforms. And then there is the use case where one developer is on a Mac and the other developer is on a PC. The Mac developer is going to see a warning that the PC developer won't, right? What about giving the PDE Build a consistent default encoding across platforms?
PDE has enhancements to help you synchronize workspace file encodings with those specified in build.propeties. Part of build.properties validation now checks project/folder/file specific encodings against properties specified in build.properties to tell you when encodings are missing or incorrect. Quick fixes help you to add the correct entries. I think this can be marked as a dup of bug 155015.
I agree as long as it works better than when Benjamin first referenced it above, because that fix actually made things worse / or at least more confused. So at that point I would say that 155015 was the cause. But it seems to me looking at the follow up on that bug that it is probably the solution as well. ;) *** This bug has been marked as a duplicate of bug 155015 ***
