Java Formatter triggered by Maven

[svanteschubert]

There is a lot of noise in the Java Sources of different editors doing different formatting. Therefore I would love to stabilize the syntax by a normalized.
Especially, I would like to make the differences between the sources of 0.9.0 and 1.0.0 less noisy.

Remember:
The version 0.9.0 - on the master branch - is basically our Apache (incubator) version. While the 1.0.0 - on the 1_0_0_SHAPSHOT branch - is the result of a painful manual merge of my work on a fork at Open-XChange with the Apache branch and on top the results of my work sponsored by the PrototypeFund.
Therefore, I started today testing with the Google Java Formatter:
https:/google/google-java-format 
In particular, I started with the following Maven plugin:
https:/Cosium/maven-git-code-format
Where I can do manual formatting on the command line via:

mvn git-code-format:format-code -Dgcf.globPattern=**/*

There are a few things I do not like very much on the result:

1. Changes within the copyright header
2. The manual formatting breaks with an out of heap error

I committed this example to a feature branch called: 
feature-formatter_variant-1_Cosium/git-code-format-maven-plugin  ;-)

[svanteschubert]

Someone reported already our problem:
google/google-java-format#413

odfdom\src\main\java\org\odftoolkit\odfdom\pkg\OdfManifestSaxHandler.java
is always the last class being processed before memory exception.

[svanteschubert]

The class OdfManifestSaxHandler.java was all a single comment.
I removed it for 0.9.0 and the format finishes successfully.
Committed all formatted source files for review purpose on the branch.

Would this suit you?

[sebkur]

Having a formatting standard for the project sound like a very good idea to me!

Going with the Google Java Style Guide and its tools seems to be a sound choice. There are formatter plugins for all major IDEs (Eclipse and IntelliJ) and also for all major build systems (Maven, Gradle).

[sebkur]

It's a bit of a pity to apply a reformatting an such a big codebase, but since there has not been any formatting standard in place up to now, I don't really see a way forward without such an action if we want to introduce this at some point. Doing it has the advantage that in the future history and comparison between branches will be a lot easier and cleaner. But it also has the disadvantage of introducing a lot of noise in the history with this one big commit with lots and lots of changes. Still in favor of using a formatting standard and applying it though.

[svanteschubert]

I fully agree, Sebastian.
As there is a big noise when we "copy over" the fork being done 8 years ago over the 0.9.0 branch, we might even be able to reduce this noise by normalization. Solely the quite last 0.9.0 commit will be very noisy. The copy from 1.0.0 will be with less noise and in the future, we should no longer have this problem.
Okay, I will enable the code normalization and releasing 0.9.0.