Bugzilla – Full Text Bug Listing
| Summary: | Use UTF-8 as default encoding for *new* workspaces | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Andrey Loskutov <loskutov> |
| Component: | Resources | Assignee: | Andrey Loskutov <loskutov> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | akurtakov, daniel_megert, schlm3 |
| Version: | 4.7 | ||
| Target Milestone: | 4.22 M2 | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=108668 https://bugs.eclipse.org/bugs/show_bug.cgi?id=479450 https://git.eclipse.org/r/96962 https://github.com/eclipse-platform/eclipse.platform.runtime/pull/22 https://github.com/eclipse-platform/eclipse.platform.resources/pull/51 |
||
| Whiteboard: | |||
| Bug Depends on: | 479450, 479451 | ||
| Bug Blocks: | 578796 | ||
|
Description
Andrey Loskutov
New Gerrit change created: https://git.eclipse.org/r/96962 @Dani: do we need to ask PMC for this enhancement? Should I ask on the PMC or cross-project mailing list? (In reply to Andrey Loskutov from comment #2) > @Dani: do we need to ask PMC for this enhancement? Should I ask on the PMC > or cross-project mailing list? https://wiki.eclipse.org/Eclipse/PMC/Minutes_2015, see October 7. (In reply to Dani Megert from comment #3) > (In reply to Andrey Loskutov from comment #2) > > @Dani: do we need to ask PMC for this enhancement? Should I ask on the PMC > > or cross-project mailing list? > > https://wiki.eclipse.org/Eclipse/PMC/Minutes_2015, see October 7. Yes, I read this, see comment 0 with my understanding of that meeting. But then why should we implement bug 479450? There is no reason to persist some weird defaults which could be set by the sysadmins in the project settings. (In reply to Andrey Loskutov from comment #4) > (In reply to Dani Megert from comment #3) > > (In reply to Andrey Loskutov from comment #2) > > > @Dani: do we need to ask PMC for this enhancement? Should I ask on the PMC > > > or cross-project mailing list? > > > > https://wiki.eclipse.org/Eclipse/PMC/Minutes_2015, see October 7. > > Yes, I read this, see comment 0 with my understanding of that meeting. > > But then why should we implement bug 479450? There is no reason to persist > some weird defaults which could be set by the sysadmins in the project > settings. Well, let's not start to discuss what people consider weird. There a tons of projects out there in CVS, Git and other repositories that do not have the encoding set (because that's how it is currently by default). The work fine. Now, if you are going to change the default for the workspace and they checkout their projects, they can run into many sever issues. The PMC has made its decision on this. This kind of discussions is why I do not use eclipse anymore and hopefully do not have to use it ever again. Our project has encoding problems BECAUSE the default was not UTF-8. The issue was specifically for new workspaces. How could this break existing projects? (In reply to Dani Megert from comment #5) > There a tons of projects out there in CVS, Git and other repositories that > do not have the encoding set (because that's how it is currently by > default). The work fine. Now, if you are going to change the default for the > workspace and they checkout their projects, they can run into many sever > issues. OK, this could be fixed during the import. If a project imported into *new* workspace do not have encoding set, we will create an error marker and provide a quick fix (set encoding). This will make the change clear and discoverable by the user, so if they run into issues due the encoding change, they will be able to trace it back to the project settings change. Also this will help users to learn about project encoding settings feature they were obviously not aware of. > The PMC has made its decision on this. I'm not sure if the PMC also considered current proposal, and I also think we should look forward if we want Eclipse remain relevant in IDE market. So because I misinterpret the original PMC decision in comment 0, and I think the current proposal could get a consensus, I believe we should send the current proposal to the PMC list. (In reply to Markus Schlegel from comment #6) > Our project has encoding problems BECAUSE the default was not UTF-8. This is also my motivation. We have environment with users all over the world, working with all possible environments (mostly Linux) but on same projects. Having system encoding as default is a pain and a constant but unnessesary error source. (In reply to Markus Schlegel from comment #6) > The > issue was specifically for new workspaces. How could this break existing > projects? Assume you created your project and the default was UTF-8 and stored it in Git. Now Eclipse decides to change the default to ASCII. You checkout your project and are doomed. (In reply to Andrey Loskutov from comment #7) > (In reply to Dani Megert from comment #5) > > There a tons of projects out there in CVS, Git and other repositories that > > do not have the encoding set (because that's how it is currently by > > default). The work fine. Now, if you are going to change the default for the > > workspace and they checkout their projects, they can run into many sever > > issues. > > OK, this could be fixed during the import. If a project imported into *new* > workspace do not have encoding set, we will create an error marker and > provide a quick fix (set encoding). This will make the change clear and > discoverable by the user, so if they run into issues due the encoding > change, they will be able to trace it back to the project settings change. > Also this will help users to learn about project encoding settings feature > they were obviously not aware of. Yes, you are reading my mind, see bug 479451 ;-) Once we have bug 479450 and bug 479451 fixed, we can reconsider the decision for this bug here. (In reply to Dani Megert from comment #9) > (In reply to Andrey Loskutov from comment #7) > > (In reply to Dani Megert from comment #5) > > > There a tons of projects out there in CVS, Git and other repositories that > > > do not have the encoding set (because that's how it is currently by > > > default). The work fine. Now, if you are going to change the default for the > > > workspace and they checkout their projects, they can run into many sever > > > issues. > > > > OK, this could be fixed during the import. If a project imported into *new* > > workspace do not have encoding set, we will create an error marker and > > provide a quick fix (set encoding). This will make the change clear and > > discoverable by the user, so if they run into issues due the encoding > > change, they will be able to trace it back to the project settings change. > > Also this will help users to learn about project encoding settings feature > > they were obviously not aware of. > > Yes, you are reading my mind, see bug 479451 ;-) > > > Once we have bug 479450 and bug 479451 fixed, we can reconsider the decision > for this bug here. Reopening in light of bug 578796 / https://openjdk.java.net/jeps/400. |