-
Notifications
You must be signed in to change notification settings - Fork 970
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Community fork? #789
Comments
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 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. |
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 |
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. |
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. |
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. |
About maintainers: About packaging: Follow-up remarks indirectly related to the fork: |
Not so far back Lightbend transferred Play Framework to the community so maybe they could do that for Config as well. |
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:
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 beHOCON Config
something like this. Another question is: may we keep original package namecom.typesafe.config
or we have to changetypesafe
with another word? Keeping package name will greatly simplify switching to forked library.@havocp @ennru Could you please answer?
com.github.xxxx
as groupname, but it has some drawbacks).@yantonov @Dkhusainov @KilowattJunkie @daniel-jasinski @aerondt @Anatoliy4041 @norrs @crash-g @JenniferJohnson89 @piorrro33 @derKrischan @jamesratzlaff @kringol @lodik @ghost @zbiljic @dwickern @karthicks
The text was updated successfully, but these errors were encountered: