kotti, aka Kotlin: The Missing Bits

The Project

I thought of naming it Kotlinist. But then, living in Berlin and realizing how much the short name of the infamous Kottbusser Tor can sound like a play on word with Kotlin, I decided to call the project: Kotti.

This is basically a library I am creating to assemble all the little utility classes, extension methods and DSLs I do find useful when developing in Kotlin. Instead of copying parts of code from one project to the other, I decided to group them here and have my applicative project depend on it.

In time, I am open to other contributors and maintainers, especially to have discussion about what to include and what not to. It's easier to achieve a better designed library when not only one set of opinion is involved.

-- Adeynack

Components

Core

kotti-core

General extensions to the Kotlin base library.

Testing

kotti-tests

Tools and assertion utilities useful for testing.

kotti-tests-kovenant

Tools and assertion utilities for the Kovenant Promises library.

GUI

kotti-swing

Extensions and DSL for developing Swing GUI applications.

Dev Ops

Tests

To execute the tests from all components:

./gradlew test

Local deployment

Deploying to the local Maven repository (on the development machine) allows other projects to use the library in its development state. It is suggested, to avoid confusion, to append -SNAPSHOT to PUBLISH_VERSION in the root build.gradle file.

./gradlew publishToMavenLocal

That also allows quick development of production software while adding and debugging features to Kotti locally.

Project using this library from local publishing need to include this in their Gradle file:

repositories {
    mavenLocal()
}
dependencies {
    compile "com.github.adeynack:kotti-core:0.1-SNAPSHOT"
}

Public version publication checklist

DISCLAIMER: This is a first iteration of the process. Not the best way. Not bulletproof. But it is a start. This will evolve over time.

1. Create an issue in GitHub with the name Publish version 0.1 (where 0.1 is the version you are about to publish).
2. Check out a clean version of master

   git checkout master
   git pull

3. Create a branch with your issue number (ie: 19-publish-0.1 is the issue number is 19)

   git checkout -b 19-publish-version-0.1

4. Check what the current version being worked on is in the Gradle project file. Per instance:

   def PUBLISH_VERSION = 0.1

   That means the current version that is about to be published is 0.1. Make sure no -SNAPSHOT suffix is present.
5. Add release notes for the current version.

• Add a new version at the BEGINNING of the list (so they are sorted by reverse date order)
• A new version starts with the version number and the date. ie: ## 0.1 - 2017-06-09
• Group changes by modules (core, swing, tests, etc.)
• Describe briefly what was added, modified or deleted.

1. Commit in that branch

   git add CHANGELOG.md && git commit -m "#19 Release notes for version 0.1"

2. Tag the current commit as the end of the current version.

   git tag 0.1 && git push --tags

3. Publish to BinTray using the instructions in the Manual publishing to BinTray section of this document.
4. Bump up the version number (usually, the 2nd digit) in the Gradle file for having in the master branch afterwards the next version to be published (useful when developing and publishing locally, to keep dependencies in client projects working).
5. Commit in that branch

   git add build.gradle && git commit -m "#19 Published version 0.1"

6. Create a pull request for this branch. Be careful in doing that during a "relative code-freeze" (make sure noone merges between the moment you tag and the moment you merge this pull request).

The end result is:

• there is a GIT tag pointing at the exact status when published, with the right version number and the release notes.
• the binaries, docs and sources are published to BinTray.
• the master branch now points at the next version to be published.

Manual publishing to BinTray

1. Make sure you are exporting the following environment variables.
   1. BINTRAY_USER containing your user name on BinTray
   2. BINTRAY_API_KEY containing your API key for BinTray. Go get your API key:
      1. Go to Edit your profile on BinTray
      2. Click API Key
      3. Click Copy to clipboard (an icon with 2 overlapping squares)
2. Make sure the version number (variable PUBLISH_VERSION in kotti.gradle) is set to the exact version you want to publish.

   def PUBLISH_VERSION = 0.1

3. Manually execute the Gradle task for publishing to BinTray.

   ./gradlew clean bintrayUpload

4. Log to BinTray and go to the Kotti repository
5. Go to the Versions section and click on the version number you just published.
6. Make sure all expected files in all components are present. Example with kotti-core:
   1. kotti-core-0.2-javadoc.jar
   2. kotti-core-0.2-sources.jar
   3. kotti-core-0.2.jar
   4. kotti-core-0.2.pom
7. In the the Kotti repository, in the Notice (look for a gray bell), click Publish