Technology for workspace management and release tooling

We’ve been on and off with discussing the need for more and better workspace tooling. This issue is intended to collect ideas and references regarding the topic to help us make an informed decision how to move forward.

Current Features

🚧 TODO: collect a list of features offered by groovyw ...

Requirements

🚧 TODO: figure out what we really need this for

References

• Tools for mono repo management like https://rushjs.io/ may already solve a couple of our problems, for instance publishing packages or checking for consistent versions
• Octokit to interact with the Github API. Official libraries for Ruby, .NET, and JavaScript, but lots of third party libs available for other languages. The launcher uses hub4j/github-api (kohsuke).

Multi-Repo Tooling

• Google’s repo tool for managing multiple repositories within the same “workspace”. Not necessarily something we should use directly, but we can take reference from their API design.

Gradle

There are also Gradle Plugins for semver version management (either via git tag or version file), like https://github.com/ethauvin/semver-gradle.

Maybe this could be integrated into the terasology-module Gradle plugin in some way, so we would use Gradle to perform this task… I don’t know how clean the code for that would, though, and how well this works with git interaction. And release plugins in general: https://github.com/researchgate/gradle-release

They usually work with version.properties or something similar, though.

CLI tooling

• CLIkt multi-platform command line parser for Kotlin
• kotlinx.cli seems to be another CLI argument parser for Kotlin
• http://yargs.js.org/ is a pretty neat library for writing CLIs in Javascript (auto-generating help messages, structure in sub-commands which automatically contribute to the overall CLI tool, …)
• PicoCLI - any JVM?

POCs

• node-gooey. Side project by @skaldarnar to elaborate a CLI tool based on Javascript using yargs and octokit/rest.js
• gooky a Kotlin implementation of prepare-module-release script with CLIkt and JGit.
• GooeyCLI - next gen existing solution

[eviltak]

My 2 cents for versioning: enforce git tagging somehow; makes it really easy to check out the exact source of a specific version of a module/lib. This isn’t applicable to snapshots of course, but if we really wanted to find a way to correlate snapshot releases to their sources, we could somehow add the 7-digit SHA value of the commit corresponding to the release in the version number/package metadata.

[skaldarnar]

Thanks for the effort and update on this @Cervator.

At this point I’m leaning towards either of gw or gooky as they are closer to our ecosystem. I still haven’t found the time to look at gw in detail, but the use of PicoCLI seems promising. Most of all, it addresses my main pain point of the Groovy scripts being really hard to maintain or extend. I may use node-gooey as little playground to test out some features or compare implementations and performance in a PoC style, but will focus on bringing one of the JVM solutions to life.

Without looking at gw in detail it’s hard to say which one to prefer. Kotlin seems to be the “modern” choice, being a bit more trendy than plain old Groovy. It also comes with some nice language features, is backed by Jetbrains, and Gradle seems to have a future with Kotlin, too. We’d need to find a convenient way of bootsrapping it, though. That’s where gw can shine, just using the whatever Groovy ships with Gradle. On the other hand, it comes with some Java boilerplate as far as I can tell. Is it the safe but boring alternative?

Let me try to turn this text into pro/con lists for both gooky and gw:

gooky (Kotlin)

• 🟢 fresh, modern language
• 🟢 backed by Jetbrains (we’re already heavily using IntelliJ)
• 🟢 Gradle shifting to/supporting configuration in Kotlin
• 🟢 CLIkt library to aid CLI tool development
• 🔴 how to bootstrap a CLI tool

gw (Java/Gradle)

• 🟢 bootstrapping with Groovy wrapper (Groovy shipped with Gradle)
• 🟢 PicoCLI library to aid CLI tool development
• 🟢 many developers are at least familiar with some basic Java
• 🔴 Java boilerplate code
• 🔴 bound to Groovy version shipped with Gradle (currently v2, printing warnings…)