Hi, I have an application that uses the 0.3-incubating version of Tamaya (just the tamaya-api and tamaya-core artifacts), and simply incrementing to 0.4-incubating-SNAPSHOT (based on a local build from the current master branch) works great. Changing ConfigurationProvider.getConfiguration() to Configuration.current() eliminates all the deprecation warnings, and all of my application tests pass. I'm looking forward to using the new release once it's ready!
A few notes, however, on some issues I encountered with the master branches of the various repositories: First, the main tamaya code (when building locally) did not pass all of the tests. I tried running the build with both JDK 11 and JDK 8 with the same results. The particular test failure is in tamaya-core, ConfigurationTest::testContent (perhaps the filtering code isn't behaving properly?): [ERROR] ConfigurationTest.testContent:52 expected:<...ltered9)(filtered10)[]"> but was:<...ltered9)(filtered10)[(filtered11)(filtered12)(filtered13)(filtered14)(filtered15)(filtered16)(filtered17)(filtered18)(filtered19)(filtered20)(filtered21)(filtered22)(filtered23)(filtered24)(filtered25)(filtered26)(filtered27)(filtered28)(filtered29)(filtered30)(filtered31)(filtered32)(filtered33)(filtered34)(filtered35)(filtered36)(filtered37)(filtered38)(filtered39)(filtered40)(filtered41)(filtered42)(filtered43)(filtered44)(filtered45)(filtered46)(filtered47)(filtered48)(filtered49)(filtered50)(filtered51)(filtered52)(filtered53)(filtered54)(filtered55)(filtered56)(filtered57)(filtered58)(filtered59)(filtered60)(filtered61)(filtered62)(filtered63)(filtered64)(filtered65)(filtered66)(filtered67)(filtered68)(filtered69)(filtered70)(filtered71)(filtered72)(filtered73)(filtered74)(filtered75)(filtered76)(filtered77)(filtered78)(filtered79)(filtered80)(filtered81)(filtered82)(filtered83)(filtered84)(filtered85)(filtered86)(filtered87)(filtered88)(filtered89)(filtered90)(filtered91)(filtered92)(filtered93)(filtered94)(filtered95)(filtered96)(filtered97)(filtered98)(filtered99)(filtered100)]"> Second, the tamaya-extensions tests seem to hang on the TestObservingProvider test. I am using a Mac in case that makes a difference. I cancelled the build after that test seemed to hang for a couple minutes. Third, by skipping the tests in the tamaya-extensions repo (mvn verify -DskipTests) and after installing the core artifacts (mvn install -DskipTests), I wasn't able to build the tamaya-extensions repository: I get a compile-time error on both the o.a.t.mutableconfig.internal.DefaultMutableConfiguration and o.a.t.microprofile.MicroprofileAdapterTest.MyConfiguration classes: org.apache.tamaya.mutableconfig.internal.DefaultMutableConfiguration is not abstract and does not override abstract method getSnapshot(java.lang.Iterable<java.lang.String>) in org.apache.tamaya.Configuration org.apache.tamaya.microprofile.MicroprofileAdapterTest.MyConfiguration is not abstract and does not override abstract method getSnapshot(java.lang.Iterable<java.lang.String>) in org.apache.tamaya.Configuration Fourth, the tamaya-consul module seems to depend on com.google.code.findbugs:jsr305, version 3.0.4, but that does not exist on Maven Central. There is a version 3.0.1 available from May 2015; is that what is meant? Fifth, I was able to install tamaya-extensions with this command: `mvn -pl '!:tamaya-mutable-config,!:tamaya-microprofile,!:tamaya-consul' clean verify install -DskipTests` using JDK8, but not with JDK11: the o.a.t.events.FrozenConfigurationTest depends on the org.omg.CORBA package, which is not available. Sixth, if I enable the tests on tamaya-extensions but omit the problematic modules (`mvn -pl '!:tamaya-mutable-config,!:tamaya-microprofile,!:tamaya-consul,!:tamaya-events' clean verify install`), I get test failures in the hazelcast module. I am not familiar enough with hazelcast to say what the exact issue is, but this is the result (it's the same under JDK8 and JDK11): [ERROR] Failures: [ERROR] HazelcaszPropertySourceTest.t01_testGetProperties:62 expected:<3> but was:<0> [ERROR] HazelcaszPropertySourceTest.t02_testGetOrdinal:92 expected:<1500> but was:<2000> [ERROR] HazelcaszPropertySourceTest.t03_tesGet:109 [ERROR] HazelcaszPropertySourceTest.t04_testCache:160 expected:<3> but was:<0> And finally (on a positive note), after installing all the extension modules (except for microprofile and mutable-config), the tamaya-sandbox repo builds, tests and installs just fine (under both JDK 8 and JDK 11). I can add these as JIRA issues later today. Best, Aaron > On Nov 19, 2018, at 9:51 AM, ajs6f <aj...@apache.org> wrote: > > Hi, Anatole-- > > It's great to see all this work going in! Will you be able to cut a set of > SNAPSHOT builds to make it available for more widespread testing? > > > ajs6f > >> On Nov 19, 2018, at 5:46 AM, Werner Keil <werner.k...@gmail.com> wrote: >> >> 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 <atsti...@gmail.com> 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* >>> >>> >>> >
