You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tamaya.apache.org by Anatole Tresch <at...@gmail.com> on 2018/11/18 21:50:42 UTC
Work pushed
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*
Re: Work pushed
Posted by Anatole Tresch <at...@gmail.com>.
Cool. Maybe I will clean out my local maven repo, too many things that seem
to break, which worked on my machine🙈.
The extension build failure (compile issues) I had when maven resolved the
core artifacts from one if the remote repos. Activating offline mode and
rebuilding everything worked in that case.
the findbugs deps in hazelcast, consul should be removed. no need for them.
So I am glad for this feedback and will fix these things within next days.
Unless somebody else is faster😉
J Anatole
Aaron Coburn <ac...@amherst.edu> schrieb am Mo., 19. Nov. 2018, 17:43:
> 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 <we...@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 <at...@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*
> >>>
> >>>
> >>>
> >
>
>
Re: Work pushed
Posted by Aaron Coburn <ac...@amherst.edu>.
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 <we...@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 <at...@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*
>>>
>>>
>>>
>
Re: Work pushed
Posted by ajs6f <aj...@apache.org>.
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 <we...@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 <at...@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*
>>
>>
>>
Re: Work pushed
Posted by Anatole Tresch <at...@gmail.com>.
the failing test in the main repo is green here. It tests that filtet
evaluation cant loop. I suspect that test execution triggers the value
evaluation more than once. this results in a too long value. Since this
test doesnt make troubles for the first time we will have to improve it.
btw if evaluation would loop we would end up with StackOverFlow... 😊
P. Ottlinger <po...@apache.org> schrieb am Mo., 19. Nov. 2018, 20:18:
> Am 19.11.18 um 11:46 schrieb Werner Keil:
> > Was this why most builds broke for a while?
>
> Last months/weeks build failures were mostly due to problems with some
> of the Jenkins nodes - the recent build failures are due to problems
> with the commits from Anatole ;-)
>
> Cheers,
> Phil
>
Re: Work pushed
Posted by "P. Ottlinger" <po...@apache.org>.
Am 19.11.18 um 11:46 schrieb Werner Keil:
> Was this why most builds broke for a while?
Last months/weeks build failures were mostly due to problems with some
of the Jenkins nodes - the recent build failures are due to problems
with the commits from Anatole ;-)
Cheers,
Phil
Re: Work pushed
Posted by Werner Keil <we...@gmail.com>.
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 <at...@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*
>
>
>