Page Comparison

When is something a good candidate for the Java Common Libraries?

• If it does not (or does not have to) tie into any project specific business logic
• If it can be useful in other projects
  • Code that is already being used - often duplicated - among multiple projects is a no-brainer here
• If it can be explained in such a way that other developers can understand how to use it

Care should also be taken with regards to the dependencies a module might introduce, the number of dependencies of common should be as

Useful locations

Conventions

...

GIT branches

do everything on develop

Maven dependencies

Javadoc

Branching & release approach

automatic snapshot after commit in git (manual snapshot: mvn deploy)

release branch created - develop branch number goes up

release branch - release gets build

commit release

merge release branch back to master

delete release branch

...

& guidelines

• Make sure to design the code for reuse: refactor the version for the common library to be specific project agnostic, modify the specific projects to use the common version
• Merge all your code to the develop branch
  • A snapshot will automatically be built by the CI server - if all tests succeed
  • Fix Sonar violations
• Review and minimize the Maven dependencies.  Where possible, use a version range.
• Update 01 - Roadmap for changes you're planning and the snapshot (development) release notes for changes you have merged to the develop branch
• Update documentation when useful
  • Add high-level documentation (overview of what's available) to Confluence
  • Ensure all classes are pretty much Javadoc complete, use the class-level javadoc for adding how-to's

Branching & release approach

All code is to be committed on the develop branch.  Branches can be created at will, but only authorized users can merge to the master branch.

Once code is committed on develop the CI server will automatically:

• build code
• run unit tests
• run Sonar analysis
• upload snapshot of module/javadoc/sources to the Nexus repository
• upload the snapshot javadoc to the javadoc location

Once a version is almost ready for release:

• create a release branch from develop (= release candidate)
• on the release branch: modify the pom.xml to release versions (eg. from 0.5-SNAPSHOT to 0.5)
• on the develop branch: modify the pom.xml to a higher snapshot version (eg. from 0.5-SNAPSHOT to 0.6)

When a version is ready to be released (project maintainer only):

• build packages (module/javadoc/sources) from release branch and upload to Nexus repository
• upload final javadoc to javadoc location
• create a tag with correct release number in the GIT repo
• merge tag to master
• merge master to develop
• delete release branch