Adjust standard Eclipse Java formatter

Removing fix version since this ticket has been closed as obsolete.

Bulk changing all open v41 issues that are not currently in Review or are BRS or docs issues to fix version v42 based on where we are in the current release schedule.

If you believe the issue was moved in error please change the fix version back to v41 and add a comment as to why it should not be pushed to v42 so that we can update the component/current status.

The problem I see is that if a developer does Format on a file, then without their knowledge the enums can be screwed up: that’s what happened to John. Can we prevent Format from joining lines in enums? That would fix the problem.

I cannot find a solution for this, except excluding a java code from formatting. I don’t want to introduce such annotation for each module, because it add will add something specific to Eclipse in source code and need to continue to maintain.

We want Java code clean. We already have formatter configured for Eclipse. When developer is writing a new code, he/she can just format a selected block (or entire file) easily. We also set up a set of rules for “clean up” code as I mentioned in my previous response.

Below is summary of what I propose.

• Do not use “Format” source code globally. We already have preferred formatter setting, and each developer can use them by selecting code block, or entire new module.

• Use “Clean up” source code globally as a part of BRS. Clean up configuration currently set up for CLDR java projects including:

  • Remove redundant semicolons

  • Remove trailing white spaces on all lines

  • Organize imports

I did not. It looks there is no good way to manage formatter to handle this.

Instead, I made “clean up” to handle more basic stuff - by the PR - which was done for

Current “Clean Up” setting does some format clean up such as - Remove trailing white spaces on all lines, remove redundant semicolons, and some other basic things.

I would suggest not to enforce formatter globally as a part of BRS - instead, we keep “reasonable” formatter settings in project, and let each developer to decide to apply it or not.