Skip to content

Latest commit

 

History

History
119 lines (92 loc) · 4.85 KB

CONTRIBUTING.md

File metadata and controls

119 lines (92 loc) · 4.85 KB
Raw

Contents

Project Setup

  • java version: AdoptOpen JDK 1.8

The project setup is quite simple. It's a standard maven project. You can import the project into any ide such as Eclipse or IntelliJ IDEA.

maven will take care of resolving dependencies. Both these IDE support importing of maven project directly. Refer to their documentation to know more on how to import maven project in it.

The project uses mvnw (Maven Wrapper) which makes sure that the version across all the builds remain same.

Use mvnw supplied with project to build instead of custom mvn installation.

Make sure you don't loose on coverage.
Current min coverage threshold: 80%
Current %age decrease in coverage threshold: 5%

Building the Project

The project can be built in multiple ways. Several IDE's directly support maven support natively. That can be leveraged directly to execute the targets. Few of the important maven targets are:

  • clean: Clean up the build i.e. delete target directory from project.
  • package: Generates the plugin jar, which can be included as part of dependencies in your maven project by explicitly specifying dependency path to a local jar. Refer maven documentation to know how to add local jar as dependency.
  • install: Generates the plugin jar and install it in your local repository. Generally local repository resides in $HOME\.m2 directory. This can then be directly included as the dependency in your project.

To build project from command line you can use these commands as per your needs. project-dir is the location where pom.xml is present.

foo@bar:~/poject-dir $  ./mvnw clean            # To clean up target directory
foo@bar:~/poject-dir $  ./mvnw package          # To generate jar
foo@bar:~/poject-dir $  ./mvnw install          # To generate jar and install it local maven repo
foo@bar:~/poject-dir $  ./mvnw clean install    # Recommanded way to do a full build

Use mvnw.cmd instead of /.mvnw in windows systems.

Approach

The base idea is to use a freemarker template which has a mock svg file and fill in all the required values obtained from the configuration to it, then render the template. This makes sure that we generate consistent and clean svg files. Once we have this svg file, we can convert it to any image format such as png, jpg etc.

The coloring and the percentage covered will be retrieved from the csv generated by jacoco report. The path of the report will be provided by user. It will then read missed branches and missed instructions as per the config and will calculate percentage.

Branching Conventions

The issues can broadly classified into 3 categories.

  1. Feature: A new functionality which needs or requested to be introduced.
  2. Bug: An unexpected behavior of the functionality
  3. Task: Routine maintenance task such as adding documentation, upgrading dependencies, verification of functionality etc.

For all the different types the branch name should be prefixed by type of issue plus the id of the issue followed by / and then make sure the description is in kebab-case

<type>-<id>/<description-in-kebab-case>

For e.g. if you have following issues

  • Feature: Add Custom Feature #10
  • Bug: This is not working #4
  • Task: Add more docs #11

then corresponding branch name will be like these

feature-10/add-custom-feature
bug-4/this-is-not-working
task-11/add-more-docs

Make sure you are using correct id for the issue, and you are creating it from correct release branch. Current development will happen on master branch. Patch and feature porting to previous version will be on release-x.y.z version.

  • x: Major version
  • y: Minor version
  • z: Patch version

This means, if you are fixing a bug for v1.0.0 then you have to create branch from release-1.0.x. If you are creating feature for current release then the branch should be created from master.

Commit Message Conventions

Commit message also follows similar conventions of using a fix prefix based on the type.

Make sure to include issue #id in all the commit message to reference it correctly to an issue, followed by comma.

<Type> #<id>, Regular Commit Message Description

For e.g. if you are working on a feature for which you want to commit, it may look like this

Feature #10, Add Custom feature

Keep the commit message as imperative, present tense: "change" not "changed" nor "changes"

irst letter in the message is in caps. i.e.

  • for feature it will be Feature
  • for bug it will be Bug
  • for task it will be Task

Feel free to drop a mail on : gahan94rakh@gmail.com or ask it on gitter if you have more queries. Happy Coding !!