Skip to content

Project Setup

If you are interested in developing and building the project please follow the following instruction.

Version control#

To get sources of the project, please execute:

git clone https://github.com/bpm-crafters/process-engine-api.git
cd process-engine-api

We are using gitflow in our git SCM. That means that you should start from develop branch, create a feature/<name> out of it and once it is completed create a pull request containing it. Please squash your commits before submitting and use semantic commit messages, if possible.

Project Build#

Perform the following steps to get a development setup up and running.

./mvnw clean install

Build Documentation#

We are using MkDocs for generation of a static site documentation and rely on Markdown as much as possible. MkDocs is written in Python 3 and needs to be installed on your machine. For the installation please run the following command from your command line:

python3 -m pip install --upgrade pip
python3 -m pip install -r ./docs/requirements.txt

For creation of documentation, please run:

mkdocs build

The docs are generated into site directory.

Note

If you want to develop your docs in 'live' mode, run mkdocs serve and access the http://localhost:8000/ from your browser.

Continuous Integration#

Travis CI is building all branches on commit hook. In addition, a private-hosted Jenkins CI is used to build the releases.

Release Management#

Release management has been set up for use of Sonatype Nexus (= Maven Central)

What modules get deployed to repository#

Every module is enabled by default. If you want to change this, please provide the property

<maven.deploy.skip>true</maven.deploy.skip>

inside the corresponding pom.xml. Currently, all examples are EXCLUDED from publication into Maven Central.

Trigger new release#

Warning

This operation requires special permissions.

We use gitflow for development (see A successful git branching model for more details). You could use gitflow with native git commands, but then you would have to change the versions in the poms manually. Therefore, we use the mvn gitflow plugin, which handles this and other things nicely.

You can build a release with:

./mvnw gitflow:release-start
./mvnw gitflow:release-finish

This will update the versions in the pom.xml s accordingly and push the release tag to the master branch and update the develop branch for the new development version.

Trigger a deploy#

Warning

This operation requires special permissions.

Currently, CI allows for deployment of artifacts to Maven Central and is executed using github actions. This means, that a push to master branch will start the corresponding build job, and if successful the artifacts will get into Staging Repositories of OSS Sonatype without manual intervention.

Run deploy from local machine#

Warning

This operation requires special permissions.

If you still want to execute the deployment from your local machine, you need to have GPG keys at place and to execute the following command on the master branch:

export GPG_KEYNAME="<keyname>"
export GPG_PASSPHRASE="<secret>"
./mvnw clean deploy -B -DskipTests -DskipExamples -Prelease -Dgpg.keyname=$GPG_KEYNAME -Dgpg.passphrase=$GPG_PASSPHRASE

Release to public repositories#

Warning

This operation requires special permissions.

The deployment job will publish the artifacts to Nexus OSS staging repositories. Currently, all snapshots get into OSS Sonatype Snapshot repository and all releases to Maven Central automatically.