Eclipse Setup
Overview
Complete setup instructions for an Eclipse installation designed to work with this project. Includes version info, desired plugins, formatter configuration and more.
Details
Download and install the latest Eclipse IDE for Java EE Developers
Eclipse Plugins
Jautodoc (find in Help → Eclipse marketplace)
SpotBugs (find in Help → Eclipse marketplace)
Checkstyle (find in Help → Eclipse marketplace)
Configuration
Download all configuration files below as developerResources.zip (NOTE the Jautodoc file may have an outdated file header, so check and fix and upload the file if that is the case)
Resource | Notes | Instructions |
---|---|---|
Code style rules | Install plugin for Eclipse (via Marketplace). (OPTIONAL) | |
Code style rules | This is really for the gradle integration, see the "checkstyle" section of build.gradle for any of the projects. No explicit action needed (OPTIONAL) | |
Configuration for JAutoDoc plugin. | Install the "JAutoDoc" plugin for Eclipse (via Marketplace). Windows → Preferences → Java → JAutoDoc (use the "Import All" button on the bottom of the screen) Also fix Java->CodeStyle -> Code Templates -> Comments -> "Overriding Methods" to look like this: /* see superclass */ Uncheck the “Add ToDo for auto-generated javadoc” | |
Line Termination, Charset | Configure these general settings | General → Workspace.
|
Eclipse "clean up" configuration for Java. | Windows → Preferences → Java → Code style → Clean Up (Use the "import" button) | |
Java formatter or the RT2 Formatter | Eclipse formatting configuration for Java. | Windows → Preferences → Java → Code style → Formatter (Use the "import" button) https://github.com/google/google-java-format https://github.com/google/google-java-format/releases/download/v1.19.2/google-java-format-eclipse-plugin-1.19.2.jar → eclipse "dropins/" folder, restart and chooose a Java→Code Style->Formatter→Formatter Implementation |
Eclipse formatting configuration for Javascript. | Windows → Preferences → Javascript → Code style → Formatter (Use the "import" button) | |
HTML formatter | ||
Java Warnings | Click on the link and follow instructions | |
Configuration for SpotBugs plugin - Static code analysis configuration | Install plugin for Eclipse (via Marketplace). | |
Javascript clean up | TBD | |
Format On Save | Under Preferences, choose Java --> Editor --> Save Actions Ideally all of the actions in "cleanup" would be included here in save actions as well. | Check "organize imports" and "format entire file". For example: |
Change Font Sizes | Under Preferences, choose General --> Appearance --> Colors and Fonts |
|
Troubleshooting
java.lang.NoClassDefFoundError: org/junit/runner/manipulation/Filter
Sometimes this error occurs in Eclipse when trying to run a unit test.
The most common cause of this is that build.gradle contains a reference to a dependency that cannot be resolved (try ./gradlew clean build from the command line)
Coding Standards to Consider (old - needs another look)
Only commit projects when the following things are the case:
Run "SpotBugs" on all java source folders, fix any errors encountered
Non-parent maven projects should not directly reference versions
where absolutely necessary, they should use variables for version info
All java errors and warnings should be removed.
Javadoc should be added and fleshed out
Imports should be properly organized and code is formatted
Service (JPA) calls should take parameters in general (except "add" and "update" calls).
List<XXX> should be used for calls without PFS parameter
XXXList classes should be used for calls with PFS parameter, and for REST call return values.
Swagger annotations should be up to date and reflect current state of REST APIs
Exception handling "catch" clauses should always properly handle errors
Low-level code (e.g. services) should NEVER handle exceptions, they should show them
The right level at which to handle an error is any code that is capable of showing the user an error message.
System.out and System.err calls should be replaced by logger... calls
Remove any explicit package names, class names, file paths, database names, or other hard coded environment information that makes assumptions about what exists and where it exists. All of this should be data-driven (either from config files or from the database).