Consider going back to having one big repo with all instrumentation

[ivantopo]

At some point when we started Kamon we had a single repository with all the code in there. It was convenient to have everything on the same place but for reasons that I really can't remember at the moment we started splitting instrumentation and reporters into dedicated repositories. Funny thing is that somehow we went back to that with the kamon-bundle, not by joining repositories but by putting all dependencies back into a single package that people can reference with a single version number.

Some of the pain points coming up often are:

• Users constantly complain about different Kamon components having different versions. This got a bit better with the bundle, but I still see examples of people using the same Kamon version variable for all their dependencies and missing important upgrades because versions are not aligned and they are not using the bundle.
• As a developer, every time a tiny change needs to be done on core or instrumentation-common there is a chain publishing locally and testing changes until things finally work that makes it quite unpleasant.
• Similarly to the above, every time there is a release we need to individually publish each one of the independent projects that were affected. Not a big deal, but this is done manually at the moment.
• Some pieces of instrumentation are very closely related to each other. For example, the Play Framework instrumentation is tied to the Akka HTTP instrumentation which in turn requires the Akka instrumentation and the Common instrumentation to work. This usually means jumping and publishing different artifacts locally for troubleshooting and fixing things.

Rough Idea:

• Pull all of the instrumentation repositories and the bundle into kamon-io/Kamon an every time we make a release, publish everything together, even if there are no changes in some of the artifacts.
• Keep separate repositories for all reporters? Or maybe a joint repo with all reporters in there.
• Keep a separate repository for Kanela.

Benefits:

• Besides solving everything on the pain points section, having a single repository can also help centralize all issues and pull requests and that can make it more manageable. I constantly find myself frustrated jumping between different issues and PRs on different projects and realizing that I left things unanswered or unattended for long. I'm not saying that this would fix the problem, but will probably help.

The challenges I see here:

• Running tests on the entire thing. This will definitely increase the time it takes to test stuff. On the other hand, we will always be testing everything together and at one, which eliminates the chance of introducing cross-module compatibility issues.
• Automating the release process. If a single release process will end up publishing all artifacts at once, that's going to take quite some time and is prone to failures, but I believe that with proper automation this can stop being a pain in the ass.

Looking forward to comments on this, it might be a good Christmas project 😄 /cc @dpsoft @mladens @adriancole

[code-colonel]

I don't like big fat jars in my distributable. Especially if I'm not using 90% of it, and especially if it's a library that's supposed to be unobtrusive like a monitoring library. Think of the users rather than the developers. Maybe work on the documentation over Christmas ;-)

[ivantopo]

Hey @code-colonel, just to be clear on something: this is just about placing all the code together in one repository, but we would still be releasing the very same artifacts we have been releasing so far. There will still be a bundle with everything inside and dedicated artifacts for each module for people who only want to bring what is strictly necessary.

In that later case, users will not need to be going from repo to repo to figure out what is the latest version of each individual dependency since all dependencies will always be released with the same version number, and that's something I keep getting asked about a lot (having the same version number for everything).

Maybe work on the documentation over Christmas ;-)

That one hurt 🤕 although still, very true. Thanks for the feedback!

[ivantopo]

Finally released here: https://github.com/kamon-io/Kamon/releases/tag/v2.1.0