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 |
---|---|---|
Checkstyle configuration | Code style rules | Install plugin for Eclipse (via Marketplace). (OPTIONAL) |
Checkstyle suppressions | 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 */ | |
Line Termination, Charset | Configure these general settings | General → Workspace.
|
Java clean up config | 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 |
Javascript formatter | Eclipse formatting configuration for Javascript. | Windows → Preferences → Javascript → Code style → Formatter (Use the "import" button) |
HTML formatter | ||
Java Warnings | Java Warnings in Eclipse | Click on the link and follow instructions |
SpotBugs excludeFilter | Configuration for SpotBugs plugin - Static code analysis configuration | Install plugin for Eclipse (via Marketplace). Windows → Preferences → Java → SpotBugs → Filter Files → Exclude Filter Files (use the "Add" button) This is really for the gradle integration, see the "findbugs" section of build.gradle for any of the projects. No explicit action needed. |
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).