Hi Guys I pushed everything now from my machine. All builds worked fine, keeping fingers crossed they will do also on the build servers. From a functional perspective I think this is basically the things that should be ready for the next release. Before I would be incredibly thankful for everybody hacing a look and probably give feedback. I try to summarize the most important points:
- Using Java 8 features on the API the current *ConfigurationProvider *can be deprecated in favour of static methods on the *Configuration *interface. This reduces the API size overall. - For having control about backward compatibility I added revapi reports to all core and extension modules, they will be generated under target/site during the normal build and can be opened using a browser. There you can easily see that especially in the SPI area some changes are definitively breaking changes, whereas the API is still basically stable, with some deprecations... - *ConfigQuery *and *ConfigOperator *were deprecated in favour of *UnaryOperator<Configuration>* and *Function<Configuration,T>.* The old artifacts are still in place for backward compatibility. - Configuration and also all other parts/modules can now be accessed passing a specific target classloader. This change actually makes really sense, but required a few incompatible changes, especially in the extensions part. The core API has been extended only. At it's core the *ServiceContext*, which actually manages all components loaded in a runtime context is now *Classloader *aware. Each configuration instance has a reference to it's own *ServiceContext*. Components that require access to the current *ClassLoader *can simply implement the *ClassloaderAware *interface (added to the core SPI). When loaded by the *ServiceContext *the current target classloader gets passed. - For consistent configuration access a similar enum like the config JSR has been added, where a *PropertySource *can declare if it supports consistent access, os is even immutable. Similaly a String *getVersion() *method has been added, where a property source can return it's version identifiers. This allows a configuration to ensure, when consistent access is supported, that the values accessed are consistent, when the versions before and after reading the values are the same. - The JSR provides a snapshot feature, which in combination with the atomic access makes sense as well. In Tamaya in the event module a similar feature already was implemented. I moved this feature into the core API and the implementation moved into the support module. The existing " *FrozenConfiguration/FrozenPropertySource*" classes have been deprecated and all accessing code has been adapted. - As already mentioned the internal representation structures ( *PropertyValue*) were extended by Map-liked data (*ObjectValue*) and array like data (*ListValue*). This enables also more complex mappings and type conversions from typical file formats to be quite easily realizable. - The homepage was extended by a simple logo, which models the "in the middle" meaning of the indian name Tamaya. I think it's nice and simple, so my proposal is to go with it for now (see also below). - Beside the logo I also added a complete new entry page with some nice (I think) advertising intros of Tamaya. To give feedback, best would be to check the site master repo out and build the site with jbake and view it on your local browser. This site also includes the overall documentation, which also has been adapted to the changes done. So it would make sense to publish the new site along the new version, once it's ready. - The JSR module implements the latest state of the JSR (one week old). - I did not update the Microprofile implementation (AFAIK it still implements MP 1.1 Config API). - Beside the collections module I also simplified the modules for consul, Hazelcast and etd support. So I think we can release them as extensions as well (they are ultra small). There will be some places (snapshots, ObjectValue, ListValue for example), where additional test code would be required, but overall things should be working quite fine and if you agree, we should be basically ready to release now. Of course, feedback or improvements are very welcome! Have a nice time. I hope you enjoy the new stuff ;-) Anatole PS: As mentioned, here the logo proposal: [image: tamaya.png] -- *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*
