Issues: https://github.com/mxenabled/path-core/issues
- Store/Redis
- Store/Vault
- encryption-service/Vault
- encryption-service/Jasypt
- Message Broker/Nats
- Fault Tolerant Executor/Resilience4J
- Exception Reporter/Honeybadger
Gradle
dependencies {
api platform("com.mx.path-facilities:platform:5.0.1")
implementation "com.mx.path-facilities:store-redis"
implementation "com.mx.path-facilities:store-vault"
implementation "com.mx.path-facilities:encryption-service-vault"
implementation "com.mx.path-facilities:encryption-service-jasypt"
implementation "com.mx.path-facilities:message-broker-nats"
implementation "com.mx.path-facilities:fault-tolerant-executor-resilience4j"
implementation "com.mx.path-facilities:exception-reporter-honeybadger"
}
Gradle
dependencies {
implementation "com.mx.path-facilities:store-redis:5.0.1"
implementation "com.mx.path-facilities:store-vault:5.0.1"
implementation "com.mx.path-facilities:encryption-service-vault:5.0.1"
implementation "com.mx.path-facilities:encryption-service-jasypt:5.0.1"
implementation "com.mx.path-facilities:message-broker-nats:5.0.1"
implementation "com.mx.path-facilities:fault-tolerant-executor-resilience4j:5.0.1"
implementation "com.mx.path-facilities:exception-reporter-honeybadger:5.0.1"
}
The Path SDK is published to Maven Central at https://search.maven.org/search?q=com.mx.path-core
master
contains the edge development for the current major version. All code merged into master
should be complete, tested, and releasable (from a feature branch).
- Developers create feature branches to introduce code changes
- When complete, a Pull Request is created from the branch
- Once approved, the pull request is merged into
master
When work on a planned major version is ready to start, a release branch will be created to hold the in-progress work. Multiple feature branches and pull requests will be generated against this branch until the version is ready for release.
We use semantic versioning. git tags are placed at the point (SHA) where the version was generated.
Current Major Version: On the current major version, minor and patch versions can be generated at any time and are expected to be backward compatible.
Past Major Versions: If a severe issue is discovered in a past major version, a release branch will be created off of the last patch version and a service pack will be released (example: 2.3.2-sp.1) from that branch.
Next Major Version: Major version releases can come follow 2 different paths:
- Planned (typical): When a large upgrade is planned, a release branch will be generated to hold the new code away from master as it is built.
- Unplanned: Some breaking changes may a) be deemed necessary for the health of the project or b) be of minor impact to users of the library. These changes will follow the normal flow and will be merged directly to master (from feature branches).
Regardless of the type, when a major version is ready to be published, a release candidate will be generated (example: 3.0.0-rc.1). This is considered an optional, production-ready release but should be used with some caution. Once the release candidate has been vetted in production, a new release will be generated without the release candidate designation (in the case of a planned version, the version branch will be merged to master at this time).
Commits must conform to the Conventional Commits specification. The commit types are used to automate version bumps, using release-please.
git clone git@github.com:mxenabled/path-sdk.git
cd path-sdk
This will install commitizen and commitlint to help ensure your commits are formatted correctly before you push them up to Github:
bin/setup
(To remove commitizen and githooks use bin/reset
)
To contribute changes:
- create a feature branch off of master or the current release branch (
git checkout -b feature/name_of_feature
) - Commit changes to branch (use
git cz
for help with conventional commit) - Push branch up
git push origin master
- create a pull request
$ ./gradlew clean build
$ ./gradlew clean assemble
$ ./gradlew spotlessApply
$ ./gradlew clean test
Via helper scripts:
$ ./bin/build $projectName
$ ./bin/assemble $projectName
$ ./bin/format $projectName
$ ./bin/test $projectName
Via gradlew:
$ ./gradlew :$projectName:clean :$projectName:build
$ ./gradlew :$projectName:clean :$projectName:assemble
$ ./gradlew :$projectName:spotlessApply
$ ./gradlew :$projectName:clean :$projectName:test
This project uses gradle to manage dependencies with dependency locking. The Vogue plugin is used to help keep the dependencies up-to-date. Vogue
Generating lockfiles for all projects
$ ./gradlew assemble --write-locks
Generating lockfiles for a single project
$ ./gradlew :$projectName:dependencies --write-locks
View out-of-date dependencies
$ ./gradlew vogueReport
Determine source of dependency
$ ./gradlew dependencies
Scan dependencies for vulnerabilities
$ ./gradlew dependencyCheckAnalyze
To view the generated report of found vulnerabilities open build/reports/dependency-check-report.html
in a browser.
To create a local build of the accessor to use in connector services use
$ ./gradlew publishToMavenLocal
This will create a local build in your local maven repository that you can then reference in other services.
On OXS using gradle the default location for the local maven repository is
~/.m2/repository/