Category:INGe Guidelines

MPDL

=Java Package Structure= We start with packaging by layer. Here we distinguish the following three layers: Inside these layers we do packaging by feature. Therefore a component is usually a slice through the three layers:
 * presentation layer
 * business logic layer
 * technical layer.

The presentation layer corresponds to the former pubman_presentation project which first remains more or less unmodified. For the business logic layer we propose the following package strucuture:
 * de.mpg.inge.business.model
 * de.mpg.inge.business.service
 * de.mpg.inge.business.controller (optional).

The model package contains the entities as PubItemVO, UserAccountVO.. (former in the common_logic project). Subpackages under the model package may be used for clearer structuring. The  service package contains the services to handle the entities of the model package. Perhaps there may be a controller package for completing the service operations e.g. by informing some listeners about update operations.

Inside the technical layers are the connectors to the repository store as ElasticSearch, SOLR or a database:
 * de.mpg.inge.tech.elasticsearch
 * de.mpg.inge.tech.solr

Utility methods (mostly static) and constants reachable from all projects are in a special jar file with package name
 * de.mpg.inge.common

The JUnit test cases are contained in a test package, e.g. de.mpg.inge.business.model.test, de.mpg.inge.tech.elasticsearch.test...

=Java Source Code Naming Conventions=

Class names of an interface end on ....Interface, e.g. EntityInterface.class. Class names of abstract classes start with Abstract.., e. g. AbstractEntityService.class. Class names of test classes end on with .....Test, e. g. EntityServiceTest.class. Avoid to put object names in the method name; this makes it difficult to extract interfaces or abstract classes; e.g. create instead of createPubItemVO.

=Java Source Code Formatting=
 * Java code formatting with maven-java-formatter-plugin. Rules for formatting are configured in a xml file. The plugin is defined in the parent pom.xml. These rules can also be used from Eclipse. Examples for formatting see https://github.com/google/styleguide/blob/gh-pages/eclipse-java-google-style.xml. Call
 * mvn java-formatter:format.


 * maven-checkstyle-plugin generates reports. Using sonarqube reports are generated automatically.


 * license-maven-plugin for headers in Java source code and for license file see http://www.mojohaus.org/license-maven-plugin/examples/example-add-license.html