Add hocon support

[CDFN]

Partially resolves #2. Still we're missing comment support. Also there's weird bug -

public interface Config {
  @DefaultString("someString")
  String testString();
}

after writing to file results in

{
    # hardcoded value
    "testString" : "someString"
}

even though the comment was never created by me. Help with troubleshooting would be appreciated :)
Addonationaly, better exception handling. Currently in HoconConfigurationFactory#loadMapFromReader only ConfigException.Parse is handled, otherwise IOException is thrown.

[A248]

With regards to exception handling, AbstractConfigurationFactory#loadMapFromReader can be loosened to throw InvalidConfigException. Then you'll be able to better map HOCON's exceptions.

One more thing, have you tested nested configuration sections? I'm not sure ConfigFactory#parseMap is the right call, but I believe it is ConfigValueFactory#fromMap. ConfigValueFactory says its 'fromAnyRef' (which fromMap calls) is the inverse operation of ConfigObject#unwrapped.

On the decision to expose ConfigParseOptions, could you elaborate on what this would be used for? Some of the options in ConfigParseOptions do not seem pertinent to DazzleConf, though I'll admit I'm a little hazy on their purpose, so I may need to look closer into this.

I'll also be available to provide advice on implementing comment support. First, let's iron out these details.

[A248]

While looking into comment support, I found out where "hardcoded value" comes from: https://github.com/lightbend/config/blob/ea45ea3767a201933eeeb9c3f0f13eacc9b51f07/config/src/main/java/com/typesafe/config/impl/ConfigImpl.java#L156

[A248]

With that in mind, I understand how to add comment support:

1. Convert DazzleConf's Map<String, Object> to lightbend-config's Map<String, ConfigValue>. ConfigValueFactory will assist in this.
2. When converting the map values (Object -> ConfigValue), add comments with ConfigValue#withOrigin and ConfigOrigin#withComments
3. Render the complete ConfigValue which is derived from the Map<String, ConfigValue>.

[CDFN]

Thank you for support with implementing it. I haven't been testing nested sections yet. I decided to expose ParseOptions to make parsing config more flexible. Should I wrap underlying options in ParseOptions into HoconOptions so there's no need to use hocon lib's objects? Also thanks for explaining how should I implement comments. I'll try my best 😃

[A248]

On further thought, I think you are right to expose the formatting library's own options in full, as this is what is done by the other format extensions (Gson and SnakeYaml). However, I think ConfigRenderOptions should have saner defaults.

• Origin comments being enabled (setOriginComments) is what causes "hardcoded value" to show up, so origin comments should be disabled by default.
• setJson would be best set to false by default. It somewhat defeats the point of using hocon over json otherwise.

Let me know if you disagree with my reasoning on these. I'm not an everyday HOCON user so you likely know more than I do.

Also, feel free to add yourself to the section in the parent pom.xml

[A248]

For new configuration formats, it would be better to encapsulate the identity of the ConfigurationFactory implementations, using static create methods rather than constructors.

The tomlj-support branch has an example of this:
https://github.com/A248/DazzleConf/blob/toml-support/tomlj/src/main/java/space/arim/dazzleconf/ext/tomlj/TomljConfigurationFactory.java

[A248]

I took care of the rest. Thanks for contributing!

[CDFN]

Thanks for finishing it. Glad I could help even a little 🙂👍