Skip to content

Latest commit

 

History

History
121 lines (88 loc) · 3.93 KB

CONTRIBUTING.md

File metadata and controls

121 lines (88 loc) · 3.93 KB
Raw

How to contribute

Working with project

Building

To compile the project, type

sbt compile

To compile the tests, type

sbt Test/compile

To build docs, type

sbt doc

Running

If some changes are made, you can test them by publishing it to the local Maven repository and using it in another project. Make sure that mavenLocal is added to the resolvers.

sbt publishM2

You can find two example applications that use Akka Serialization Helper:

cd examples/akka-cluster-app

or

cd examples/akka-persistence-app

And follow instructions from projects' README files.

Testing

To run unit tests, type

sbt test

To run sbt plugin integration tests, type

sbt scripted

Debugging

To debug compiler plugin used in another project, run sbt in target project with debug port open

sbt -jvm-debug 5005

and connect to it using remote JVM debug with your favourite IDE that has this project opened.

Then, in the target project sbt shell, type compile. If the compilation finished, but your breakpoints didn't register, try run instead.

Remember to type clean after successful compilations. Otherwise, incremental compilation might determine there is nothing to compile and won't run the plugin you are testing.

Profiling

To profile akka-serialization-helper compiler plugin used in another project - follow instructions from https://www.lightbend.com/blog/profiling-jvm-applications You might as well use any other profiler, but using https://github.com/jvm-profiling-tools/async-profiler with flamegraphs should be really effective and easy to achieve (+ no unexpected bugs / issues / errors).

Code quality

Before committing, don't forget to type

sbt scalafmtAll scalafixAll scalafmtSbt

to format the code, .sbt files and check imports. Run this command in the following directories:

  • the base directory ( . )
  • examples/akka-cluster-app
  • examples/akka-persistence-app
  • examples/event-migration You can use pre-commit hook, provided in ./pre-commit, to do formatting and checking automatically.

Additionally, all warnings locally are escalated to errors in CI, so make sure there are none.

Compatible JDK versions

To build this project successfully, use JDK version 11 or higher. It won't work with lower java versions.

Releasing

Releasing is done automatically by sbt-ci-release sbt plugin (read more on the plugin's GitHub page)

Snapshots

The new SNAPSHOT version is automatically published by GitHub Actions to Sonatype OSS Snapshot repo every time a new commit is pushed to main.

To depend on the newest version with sbt, add the following setting:

ThisBuild / resolvers += Resolver.sonatypeRepo("snapshots")

to both build.sbt and project/build.sbt (so that the sbt plugin added in project/plugins.sbt can be resolved).

Maven Central

Releases to Maven Central are triggered by pushing a lightweight git tag with a version number.

To publish version x.y.z, type in the console (on main branch)

git tag vx.y.z
git push origin vx.y.z

The tagged commit is then released to Maven Central.

Note that we are using an early semantic versioning scheme.

Github Releases

Github Releases are done automatically - with settings defined in the publish-release-config file. Release is published when new "vX.Y.Z" git tag is pushed to the main branch.