Hi, How did a "bloated" Tamaya with a total codebase of just under 2MB in master suddenly become over 20 MB in the "lean" version?;-O
Also the "code" part (which is what should be sufficient to build the minimalistic API) does not compile with Maven. [ERROR] /C:/Users/Werner/git/tamaya-next-tamaya-next/code/api/src/main/java/org/apache/tamaya/spi/ConfigurationProcessor.java:[74,28] cannot find symbol symbol: class ProcessorContext location: interface org.apache.tamaya.spi.ConfigurationProcessor [INFO] 1 error I'm not sure, if the term "ConfigurationProcessor" for what used to be a "*Source" really sticks. But being able to compile and run it especially with real life use cases (e.g. how the Joda module now works after those changes I'd be happy to start with. Regards, Werner On Sun, Jul 31, 2016 at 1:55 AM, Anatole Tresch <[email protected]> wrote: > Hi guys > > as promised I have put together the current state of a streamlines API > including adaptions needed on all the current codebase. This can be found at > > https://github.com/atsticks/tamaya-next > > The API especially is here: > > > https://github.com/atsticks/tamaya-next/tree/tamaya-next/code/api/src/main/java/org/apache/tamaya > > Short summary of the ideas: > > - define *Configuration* by simply providing String get(String key). > - organize configuration as an ordered list of " > *ConfigurationProcessor*" instances aka *processor chain*, which > basically are a more generic combination of PropertySource and > PropertyFilter, thus removing the need for PropertyFilter as well as > other heavy decision such as when to filter. The data access call is > simply String > get(String key, ConfigurationProcessorContext context); > - The *ConfigurationProcessorContext* gives access to the remaining > procerssor chain and also helps to reduce boilerplate code in the > implementations. > - The Configuration itself can be created using a > *ConfigurationBuilder*, which basically is a programmatic API to > construct the processor chain. This builder is provided by a > *ConfigurationBuilderFactory*. > - The factory also can load the default chain, which is the basic > mechanism we had in place, loading sources, source providers and use their > ordinals for priorization. Nevertheless the factor allows to build up your > own thing, or allows to reproduce the "default" configuration bas calling > factory.loadDefaults().build(); > - So the ConfigurationFactory is also the SPI used by the > ConfigurationProvider using the default functionality as described > above. > > This results in 4 API artifacts and a SPI with another 4 artifacts, which > allow us to do anything we already have with relatively controllable > efforts: > [image: Inline-Bild 1] > > > Just a few side nodes: > > > - there is the adapter extension (*tamaya-adapter*), which allows you > give an adapter singleton to adapt configuration to something else. E.g. > this allows us to add functionality for types and defaults: > TypedConfiguration cfg = > ConfigAdapterManager.adapt(TypedConfiguration.class); > ConfigWithDefaults cfg2 = > ConfigAdapterManager.adapt(ConfigWithDefaults.class); > ... > - Similarly ConfigProcessor instances can implement Mixin Interfaces > such as Scannable (another module SPI from *tamaya-scannable*) to > provide additional capabilities. This can similalry used to provide access > with getProperties(). > > I will be now on holidays for 2 weeks. I will be able to answer mails, > but will not have access to a notebook or a computer bigger than my > smartphone. So hangouts work well, coding will be limited ;). Please look > at the code (especially the API and core parts, the modules are not yet > fully buildable ;) ). > > J Anatole > > Suggestion/question: next hangout on Monday evening ? > > > -- > *Anatole Tresch* > PPMC Member Apache Tamaya > JCP Star Spec Lead > *Switzerland, Europe Zurich, GMT+1* > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > *Twitter: @atsticks, @tamayaconf* > >
