Potential Project Restructure

[ckipp01]

While splitting this out from Bloop I came across a few things that I'd like to get some thoughts on. I wouldn't even consider a restructure like this without some large benefits, so let me explain a couple issues I see currently and how restructuring could improve the situation.

First an overview

Just to all be on the same page. This repo supplies users with two things:

1. Prove the actual Config.File domain classes.
2. Provide ConfigCodecs to write and read the Config.File`

Both of these are bundled into one artifact, meaning that whatever choice bloop-config makes for the codecs, it's bringing the dependencies and limitations with it. Currently the codes are written with jsoniter-scala, which is an opinionated choice. I saw this for a couple reasons, but mainly:

1. I'd like to cross publish bloop-config to Scala 3. This should be very easy seeing how small it is, but in order to do that, we have to bump the version of jsoniter we use, and by doing that we drop support for Java 8.

Potential restructure

While thinking about this a bit more and talking with others I'm curious if there would be support for a partial restructure. As said above, everything right now is just in a bloop-config artifact, but we could break this out into something like the following:

1. bloop-config which becomes just the actual case classes that are used and we define a ConfigReaderWriter interface that defines the write and read methods in here. Whatever tool is using this could then feel free to implement there own. This would be helpful as some projects already redo this as you can see in Mill here. Then if other projects want to continue to use jsoniter, they can do that by included another package, which I'll outline below:
2. bloop-config-jsoniter which has ConfigReaderWriter implemented with the current codecs that are in ConfigCodecs currently.

By doing the above we could:

1. Cross publish bloop-config to Scala 3 with no issue. Then tools like bleep wouldn't have to use for3Use213.
2. Unbundle jsoniter from the core, so tools like Mill could just use their own without bringing in jsoniter. Plus, we wouldn't have to worry about bumping and dropping support for jdk 8.

Some things to consider

• This would require a major version bump for bloop-config
• Introduces a bit more complexity, but not too much

I'd love to get some thoughts on this @adpi2, @tgodzik, and @Duhemm. Also CC @lefou since you might be interested in this due to the Mill aspect.

[lefou]

Your argumentation sounds reasonable. Meanwhile, I was able to just exclude the jsoniter dependency in Mill (com-lihaoyi/mill#2159), as we use upickle for JSON serialization anyways. So, jsoniter is kind-of optional and only used for serialization. There is no guarantee though, that this will work in a next release, so some official packaging without jsoniter might be better.

Also, there is probably no real need to introduce the mentioned traits, other than to ensure, all your provided JSON codecs can be used via the same API.

Just a remark that if you are going to split up the packaging, you should also use different Java packages, so we don't end up with split packages across multiple archives, which is known to cause trouble.

Also, once you ship each JSON codec separately, you can support jsoniter for Scala 2.13 and Java 8 compatibility as well as jsoniter for Scala 3 by just providing two different packages.

[tgodzik]

I think this would be fine, the only question is whether it's something we need to work on now. If it's excluded in Mill and the only other place using it is Bloop it might be a bit of over engineering to have separate jars etc. However, for sure that would be more future proof, so maybe it's the right thing to do?

Anyway, no strong objections from me.

[lefou]

I think this would be fine, the only question is whether it's something we need to work on now. If it's excluded in Mill and the only other place using it is Bloop it might be a bit of over engineering to have separate jars etc. However, for sure that would be more future proof, so maybe it's the right thing to do?

Anyway, no strong objections from me.

This PR with the exclusions is not yet merged. Also, I haven't reviewed whether it is safe to do so. Our integration test does not fail, but that gives not 100% safety. Also, if there is agreement that it would be the right move, why not settle with doing in now? If there are not so many consumers (yet), this is the perfect argument for doing it rather soon. It also help to relax the Scala 3 vs Java 8 dilemma, we discussed somewhere else, as there could be two jsoniter codecs for bloop-config.

[lefou]

Although a mayor bump in necessary, the change to the Bloop Config is going to be source compatible, as far as I can tell. Only the JSON stuff might need some review on the consumer side.

[lefou]

Apologies, if my response felt offensive. I myself don't like such harsh "Why not ..." responses. That was not intended.

[tgodzik]

No worries, I agree that long term this makes sense, just that there is a lot of things related to Bloop we want to fix, so I felt this is not the most urgent.