Modularize project to minimize unnecessary transitive dependencies

[feature]

I currently think the amount of supported formats and dependencies is excessive for most projects. I think we should move the JSON, XML, YAML, HOCON, and TOML providers into separate modules, and let users opt-in to use these different providers. Furthermore I also think it would be a good idea to move the functionality for loading from git repositories into a different module. The primary motivation for this is to reduced amount of dependencies on the core library.

What I propose is to have 7 different modules in total;

• konf-core
• konf-json
• konf-xml
• konf-yaml
• konf-hocon
• konf-toml
• konf-jgit

I've forked the project and started making progress on this in a separate branch. I intend the API to stay mostly unchanged, however it's necessary to remove some fields and replace them with extension properties (DefaultLoaders specifically). The README and documentation must be updated to reflect these few changes, and add that you must manually add providers as a dependency, and register them to the Provider companion object.

[char]

If there are formats that you aren't using, have you tried doing anything like:

implementation(myKonfDependency) {
  exclude(module = "org.eclipse.jgit")
}

Does this result in Konf failing outright or just throwing an exception whenever the end-user tries to interface with JGit?

[uchuhimo]

@feature I agree with your proposal. I'm sorry that I don't have enough time to do such a large project refactor in these two weeks. Your pull request is welcome if you finish this refactor in your branch.

[feature]

@half-cambodian-hacker-man
I was considering simply just doing that, however it's not a very nice approach and it creates pitfalls in the library that would most likely crash the application, if you happen to trigger any of them by accident.

@uchuhimo
I expect to be able to get it done within a few days. Jackson seems to be used throughout multiple parts of the library, so I'm not yet sure if I can extract that into a different module or not, regardless if I it is not possible, keeping it as a dependency in the core module is a reasonable compromise to me. When I'm done modularizing the project, I'd appreciate some help to ascertain that the all the build configurations are correct, and that the documentation is up-to-date. I'll make sure to try to attach a comprehensive checklist to my PR.

[uchuhimo]

@feature Jackson is used in mapping between config items and fields in classes, so it is a necessary dependency in the core module. I think we will finally have 6 different modules in total (except konf-json, it will be part of konf-core).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 30 days if no further activity occurs, but feel free to re-open a closed issue if needed.

[pie-flavor]

what's the status on this? I too want this feature.

[feature]

I made a pull request for this issue. All the modularization is done, I just need to update the documentation, and tests. I'm a busy at the time, so any help on the PR would be appreciated.

#23

[uchuhimo]

@pie-flavor @feature I release a new version v0.15, which contains the modularization feature. Documents and tests have also been updated. You can give it a try.