Community fork?

[radist-nt]

Since Lightbend is not interested in futher library development, but according to the recently opened issues, there many people who interested in new features, let's discuss the creation of library fork.

Key point:

• License question. Apache 2.0 license allows to fork, but doesn't allow to keep original name. This is a question to Lightbend: what should be changed in fork to avoid any license-related issues? May we keep Config word in library name (since this word is widely used and I doubt it could be considered as a trademark)? For example, new library name could be HOCON Config something like this. Another question is: may we keep original package name com.typesafe.config or we have to change typesafe with another word? Keeping package name will greatly simplify switching to forked library.
  @havocp @ennru Could you please answer?
• Fork license should be the same as original (Apache 2.0) to allow thouse who use Typesafe Config switch to fork without investigating license questions.
• Maintainers team. This is a key question: who are interested in futher development and ready to spend some time for library maintenance?
• Infrastructure question. I think, we can use github for almost everything (including github actions for ci). But creating maven coordinates requires a valid globally-accessible hostname (of course, we can use com.github.xxxx as groupname, but it has some drawbacks).
• Build system. Sbt is scala-based and is not familiar to many java developers (when I created my PR, I had an issues with tests and had to create local pom.xml and develop as it was java project and then ported my tests to scala). Should we switch to another system which is more common to java developers (maven/gradle)? Do we need to rewrite tests to java after changing build system?
• What should be done first (after answering questions above):
  1. fork repository
  2. prepare and test configuration for github-actions
  3. register the group id at Sonatype
  4. find all PRs closed by Lightbend due to their decision to stop extending functionality and recreate them on forked repository
  5. copy issues related to PRs to the forked repository
  6. decite which PRs are ready to be merged
  7. prepare the first forked release

@yantonov @Dkhusainov @KilowattJunkie @daniel-jasinski @aerondt @Anatoliy4041 @norrs @crash-g @JenniferJohnson89 @piorrro33 @derKrischan @jamesratzlaff @kringol @lodik @ghost @zbiljic @dwickern @karthicks

[havocp]

Hi Andrey, I can't answer the legalities of the project name question, that will be up to Lightbend. To be clear, I have not been affiliated with Lightbend since many years ago so anything I say is just me as an individual.

For the Java package name, I believe this is on-point and you shouldn't have to break compat, but I am not a lawyer.

From a non-legal perspective, a nuance of the project is that it isn't exactly a HOCON parser, though it contains one, the API isn't designed as a general parser (a longstanding open feature request is to be able to get a real parse tree). As a parsing library, the code is kinda slow and the API is kinda odd. The API is actually designed as a configuration library which is subtly different, and it works much better when used for that.

So I might avoid a name like java-hocon that implies it's the HOCON parser, because someday it could even make sense to split the parser out of this project, and one feature request has even been to add some kind of plugins like YAML plugins.

What should you name it, well, I am notoriously bad at naming things :-) but thought I'd suggest that some logical components of this thing are the hocon-spec, the java-hocon-parser, and then whatever you'd call the Config APIs that let you stack up and merge Config instances and access a global default instance. Those are three logically separate pieces, to me. Note, I am not suggesting that step 1 is to try and split that up - it's probably quite difficult code-wise to actually split out the parser. Just that you might think of it as having three parts in the long run. I would probably try to come up with a name for the configuration library as the initial project name, and then later name the parser and the spec projects if you ever split them out.

An advantage of splitting out the spec someday is that maybe the maintainers of the various other HOCON parser implementations would be able to join that repo and you could get some good peer review on spec changes.

I'm pretty sure maven and gradle can run Scala tests just fine but I could be wrong. Build system just depends on what the volunteers you find are comfortable with. The code here is much trickier than it may appear and I would suggest you make it a priority to preserve extensive test coverage, if you want it to keep working. I think I was using jacoco or something to measure coverage.

In a fork, I'd suggest having a clear back compat policy for both the ABI and the spec format, before you start trying to review PRs. Breaking back compat is a very common reason that PRs aren't workable so you'll want to know whether you are accepting incompatible changes and be able to point people to the policy. Just a thought though.

[ekrich]

When I created a fork after porting the code to Scala, I was told I needed to change the package which I did. (org.ekrich). I just named the project sconfig for Scala Config. A scalafix setup was created to automate changing the package name and some other minor changes like dropping () in some cases for Scala. The project is probably fine for just Scala (and all the different versions and platform) but is not that popular and probably not that great for Java since it is almost pure Scala and I wouldn't want to add any of the Java reflection improvements. https://github.com/ekrich/sconfig

[ennru]

Thank you for your interest in "Typesafe Config" and the will to take it further.

Reusing the same package namespace from a different library sounds like a bad idea. Projects could easily end up with both libraries on their classpath with unpredictable results.

[jamesratzlaff]

I love the idea of a community fork. Using this as a configuration library is why I created the SPI PR, since the folks that wanted to use this library were dealing with a ton of YAML files.

[radist-nt]

Reusing the same package namespace from a different library sounds like a bad idea. Projects could easily end up with both libraries on their classpath with unpredictable results.

To prevent classpath conflict, original library should be excluded by build system (i.e., for maven you can provide exclude dependencies for artifacts and add banned dependencies with maven-enforcer-plugin). This is more simple solution then updating imports in all files which depends on configuration library.

[yantonov]

About maintainers:
Probably I can spend some time on it, for me also it's a feature-complete library so from my perspective it's important only to fix bugs (using minimal changes) for the existing functionality/features to prevent spending time again and again on the same issues.

About packaging:
As it was mentioned above, definitely it will be nice to preserve the package name, otherwise, the migration process will be painful.
Even if changing the package is a mechanical procedure and can be automated, not sure that it will be inspiring to approve such changes to many projects; because in some cases this library can be used at the SDK level, so almost every related project can depend on it in such kinds of cases.

Follow-up remarks indirectly related to the fork:
There are some bugs around inheritance, probably here we have too much complexity that's not worth it.
Just an example: if you have common settings and some settings that depend on the environment, in that case, it's possible to put common settings separately (using name convention), and explicitly define values for all fields that depend on the environment explicitly for each field\environment.
In that case, there is no need for the additional syntax, there are no overrides because either you use a value from the common block or from the environment block, and therefore complexity in the parser\library code can be reduced (but from the practical perspective you still have a clear view of what's going on, here are common settings, here are environment related settings).
Here I'm talking about implementing some logic on the app\sdk side (around the config library) and therefore the library itself (or the core functionality for parsing, etc) can be simplified and the number of edge cases can be reduced.
It's not directly related to the fork, but if some non-trivial time is needed for support \ create a fork \ migrate, probably there are other alternatives for example (here I'm talking about the long-term perspective, also about new (even non-existing now) projects), using only a subset of the functionality probably within another (or at least smaller) library in terms of feature set.

[ekrich]

Not so far back Lightbend transferred Play Framework to the community so maybe they could do that for Config as well.
https://www.lightbend.com/blog/on-the-future-of-play-framework
https://discuss.lightbend.com/t/on-the-future-of-play-framework/8920/2