Hi, Was this why most builds broke for a while?
Thanks and Regards, Werner On Sun, Nov 18, 2018 at 10:51 PM Anatole Tresch <[email protected]> wrote: > 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* > > >
