Public classes which are undocumented and/or for internal use

[dmlloyd]

There are several public classes and interfaces in the project which don't have documentation or are clearly for internal use. The list is:

• io.smallrye.config.ConfigLogging
• io.smallrye.config.ConfigMappingClassMapper
• io.smallrye.config.ConfigMappingMetadata
• io.smallrye.config.ConfigMappingObject
• io.smallrye.config.ConfigMessages
• io.smallrye.config.ConfigValidator
• io.smallrye.config.SecretKeysHandler
• io.smallrye.config.SecretKeysHandlerFactory
• io.smallrye.config.AbstractMappingConfigSourceInterceptor
• io.smallrye.config.MapBackedConfigValueConfigSource
• io.smallrye.config.ConfigMappingGenerator
• io.smallrye.config.ConfigMappingLoader
• io.smallrye.config.ConfigMappings
• io.smallrye.config.ConfigurableConfigSource
• io.smallrye.config.ConfigValuePropertiesConfigSource
• io.smallrye.config.DefaultValuesConfigSource
• io.smallrye.config.DotEnvConfigSourceProvider
• io.smallrye.config.EnvConfigSource
• io.smallrye.config.ExpressionConfigSourceInterceptor
• io.smallrye.config.Expressions
• io.smallrye.config.FallbackConfigSourceInterceptor
• io.smallrye.config.KeyMapBackedConfigSource
• io.smallrye.config.LoggingConfigSourceInterceptor
• io.smallrye.config.ProfileConfigSourceInterceptor
• io.smallrye.config.PropertiesConfigSource
• io.smallrye.config.PropertiesConfigSourceProvider
• io.smallrye.config.PropertiesLocationConfigSourceFactory
• io.smallrye.config.RelocateConfigSourceInterceptor
• io.smallrye.config.SecretKeys
• io.smallrye.config.SecretKeysConfigSourceInterceptor
• io.smallrye.config.SecretKeysHandlerConfigSourceInterceptor
• io.smallrye.config.SmallRyeConfig <- this especially should be documented
• io.smallrye.config.SmallRyeConfigBuilder
• io.smallrye.config.SmallRyeConfigProviderResolver
• io.smallrye.config.SysPropConfigSource

These types either need to be documented with clear API contracts, or made non-public (even if they're marked as experimental). Additionally, classes which are kept public should be examined to see if they should be final, and their constructors should be examined to ensure that all public constructors are properly documented, and that the implicit constructor is intended to be public (it's better though to have explicit constructors because then they can be documented).

Relates to #295.

[radcortez]

Relates to #295.

We actually reverted that due to split packages in #300.

A few of these while not public APIs, need to be public because of our usage in Quarkus. Regardless, I'll have a look into the list and try to detail each case.

[dmlloyd]

Oops, I meant to reference #989. My concern with #989 is that the API classes are all already in the root package in -core so having another API module isn't really going to be possible without splitting packages.

[radcortez]

Yes, I know :(

We didn't want to change it at that time not to break users, and now the situation is far worse. It bothers me that we have a flat package structure with so many classes. I've already deprecated a few things that have little to no use to remove them.