Developer Guide

Project Goals

The project goals are already described in the Home-Site of the wiki. But here are some additional none functional requirements:

• Quality: The code should be tested very good to prevent from errors
• Usability: The library should be easy to use for validation
• Maintainability: low cost for maintainance
• Documentation: for public api in the validations package

Coding Goals

• Easy use of the API for validation
• No Sonar Issues
• More than 100 % Test Coverage
• No IntelliJ Idea warnings
• Clean Code (just to name some)
  • 0 % duplicates
  • Only the public API is documented using Java-Doc
  • Methodnames should describe what the methods are for
  • Small methods and classes considering the separation of concerns
  • ...

Definition of Done

• Feature is implemented
• all necessary cases are tested
• more than 100 % Code coverage
• no sonar issues left
• no IntelliJ Idea warnings left

Project Structure

• easy-validaton-parent
  • easy-validation
  • easy-validation-examples

easy-validation-parent

This is just the root module which contains the other required modules

easy-validation

This module contains the code of the library which is published

easy-validation-examples

This module contains some examples how you can use the library. The goal of the project is to provide the example code for the examples in the wiki. The examples are put there to

• guarantee that the example is compilable
• and if necessary that the example can be tested in the build

Decissions

Providing validations as static methods

I thought it's the easiest way of using the validations. The other possibility would have been a builder. But because

• the builder is more complicated to use
• the implementation of the builder is addtional code for maintainance I decided for providing static methods which could be simply imported.

How to provide the possibility to use an error code

I decided to provide the api once for validtions without, and once with error code, in separated classes (StringValidations, StringValidationsWithErrorCode). The reason is that I thought that

• users would either use error codes or not. But normally they wouldn't mix it
• the method count within one class is just the half
• it gives more overview if you see only the methods you are interested in

What to put to Common-Validations

First it was thought only for general Object validations, e.g. Equals, or some specialized for Comparable. But than the validation for boolean was necessary and I thought it's best to put it there. I didn't want to create a validation class for just two methods.

Build

Maven is used for building the project. I just didn't use gradle because till now I didn't came in close touch with gradle.

Releasing

Currently I do not know of how to give someone else the permission to sonarcloud.io and to oss.sonatype.org. To be honest, currently I would prefer merge requests. And I will do the remaining steps.

Prerequisites

For maven releasing are some general prerquisites. E.g. the executable for calculating the checksum. These general requirements are not covered here. This information can be get from here

• oss access configured in the settings of maven as server id ossrh
• github access configured in the settings of maven as server id github
• profile ossrh, activated by default which provideds the gpg executable for the checksum
• profile sonar, activated by default, which points to sonarcloud.io

invoking the release build

Currently somethings wrong with the maven configuration. Therefor 2 steps are necessary as long as Issue #6 isn't resolved.

mvn clean install
sh mvn-release-with-sonar.sh

The build take a while because of the deployment to the central maven repositore. It is recommended to not loose the interconnection while releasing.