* Minor manually done fix up of fineractdev-eclipse-preferences.epf file
This in theory should not change anything about the conventions,
it's just a first manual clean up of this very old file here.
The few extra new lines are what I found when exporting Preferences.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* fineractdev-eclipse-preferences.epf imported and re-exported in Eclipse.
This in theory should not change anything about the conventions, as
presumably Eclipse during an Import and re-Export of an EPF just adds
new settings, and perhaps removes old settings. I've not actually made
any manual changes in Preferences in this step.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* fineractdev-eclipse-preferences.epf "import" in line with Checkstyle
The non-import related Code Formatter settings may need further tuning;
this will be done in future changes; the focus in this round is on
import.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* Use Eclipse's Source > Organize Import to re-order all import statements
This uses the fineractdev-eclipse-preferences.epf from the previous
commit, which just so happens ;) to exactly match the expected import
rules which the next commit is going to enforce using Checkstyle.
This is of course not specific to only Eclipse per se; other IDEs can
be similarly configured to match these coding conventions; I just happen
to have used Eclipse.
Related to https://issues.apache.org/jira/browse/FINERACT-821
* Activate and Enforce all Checkstyle import related new checks
and update the README to explain Checkstyle, and the availability of the
Eclipse Preferences configuration file which matches the import
code format conventions which are now enforced.
Contributions for a similar preferences file for other IDEs welcome! ;)
Related to https://issues.apache.org/jira/browse/FINERACT-821
Thanks to prior work for SpotBugs, this passes without requiring any
code adjustments. (Fineract had a nubmer of problems in this space
before the SpotBugs work.)
Enabling this helps to ensure non-regression so that no new equals() and
hashCode() related bugs creep in. (This does overlap a little bit with
SpotBugs, but the build time overhead to run the extra check is
completely negligible, so it seems worth having this. If only just in
case SpotBugs for whatever reason in the future would get deactivated
again.)
