Yep, I am already working on it... 2014-11-29 23:15 GMT+01:00 Gerhard Petracek <[email protected]>:
> @anatole: > it would be nice if you can select the simplest and most central use-case, > push a test for it and start an own "[DISCUSS] ..." thread on this list. > > regards, > gerhard > > > > 2014-11-29 23:00 GMT+01:00 John D. Ament <[email protected]>: > > > Makes sense to me. +1 > > > > On Sat, Nov 29, 2014, 16:53 Andres Almiray <[email protected]> wrote: > > > > > Whar about this: let's continue in the JDK8 route and ser how far the > new > > > syntax and APIs can take us. It may be the case that after exploration > we > > > discover JDK8 holds little to no advantages to Tamaya's cause OR (as I > > have > > > high hopes) JDK8 is instrumental to Tamaya's success. > > > > > > Bottom line is we wont be able to tell which path is best if we don't > try > > > JDK8. > > > > > > Sent from my primitive Tricorder > > > > > > > On 29/11/2014, at 21:58, Anatole Tresch <[email protected]> wrote: > > > > > > > > Hi > > > > > > > > as Gerhard mentioned Java 8 guarantees not necessarily a better API, > > but > > > > Java 7 makes it definitively harder! And remember the original > > incubation > > > > proposal says we want to create a modern and functional API. Also I > > would > > > > like to mention (I will mention it exactly once, since it is only one > > > > aspect of the work we plan to do here) that if we want to be part of > > some > > > > kind of future standards, regardless if for Java SE and/or EE, Java 8 > > is > > > a > > > > precondition. Oracle will never accept an API proposal that is built > on > > > > Java 7. > > > > > > > > Adding the use case aspect does not help related to that topic, so > > please > > > > let that things out as of now. We have to sort out the basics first. > On > > > > which Java version things are build is for me an absolute crucial > > > decision, > > > > we cannot postpone. I did a proposal how to sort that out, still > > leaving > > > a > > > > door open for Java 7 support: > > > > > > > > - * Design for the future (Java 8) and provide a (maximal) > > compatible > > > > backport for Java 7 once the first release is out and a majority of > > the > > > > team members want to do so. * > > > > > > > > So I tend to do a vote on that and see what is the outcome. > > > > > > > > Be aware also, that if we decide for Java 7, we must have to check if > > the > > > > existing supporters are still are on board, since the original > > incubation > > > > proposal was IMO clearly targeted for Java 8 (though not explicit). > > > > > > > > If we have a decision here, I hope we can start to focus on the > > problems > > > we > > > > want to solve (aka use cases and requirements). > > > > > > > > WDYT? > > > > > > > > -Anatole > > > > > > > > > > > > 2014-11-29 20:00 GMT+01:00 Gerhard Petracek < > > [email protected] > > > >: > > > > > > > >> imo we should focus on the api first. using java 8 is no guarantee > to > > > get a > > > >> better api. > > > >> > > > >> as mentioned in a previous thread, we need to re-visit the existing > > > parts > > > >> anyway. > > > >> e.g. at deltaspike it was quite challenging to merge the existing > > > >> approaches until we switched to an use-case based procedure. > > > >> we started to write tests to reflect the different use-cases > starting > > > with > > > >> the most trivial one. > > > >> that increases the test-coverage and users can have a look at those > > > tests > > > >> to see the usage of the different parts. > > > >> furthermore, it ensures that more advanced use-cases won't impact > > > simpler > > > >> uses-cases. > > > >> in the test-suite we use packages which follow the following format: > > > >> [project-package].[area].uc[number]. > > > >> the use-case numbers don't reflect the priority, however, usually > the > > > lower > > > >> numbers reflect the most common usages. > > > >> > > > >> i would prefer to try such an approach also for tamaya. it might be > a > > > bit > > > >> more time-consuming, but we can do everything step-by-step. > > > >> moreover, we don't start with random discussions. even if we would > end > > > up > > > >> with almost no api-changes (which i don't expect), we would get a > nice > > > >> test-coverage at the end. > > > >> > > > >> regards, > > > >> gerhard > > > >> > > > >> > > > >> > > > >> 2014-11-29 11:42 GMT+01:00 Romain Manni-Bucau < > [email protected] > > >: > > > >> > > > >>> I still think api is broken (access shouldnt be static like that, > > maybe > > > >> we > > > >>> can take inspiration from jcache), default method just shows api > > should > > > >> be > > > >>> split in 2 interfaces (provider and analyzer maybe?) etc... > > > >>> > > > >>> If solution is commons configuration and tamaya reason is j8 then > why > > > >>> creating a new project? > > > >>> Le 29 nov. 2014 11:32, "Anatole Tresch" <[email protected]> a > > écrit : > > > >>> > > > >>>> Dear all > > > >>>> > > > >>>> I miserably failed to send you feedback on the Java 8 topic due to > > the > > > >>> f... > > > >>>> spam checks: > > > >>>> > > > >>>> - in html > > > >>>> - linked to Google Docs > > > >>>> - as PDF > > > >>>> - as link to the blog > > > >>>> > > > >>>> I now published a blog on it at: > > > >>>> javaeeconfig.blogspot.com/2014/11/configapi-java-7-vs-java-8.html > > > >>>> > > > >>>> Hope you can read it ;) > > > >>>> > > > >>>> Cheers, > > > >>>> Anatole > > > >>>> > > > >>>> PS: Can please anybody change this spam levels here for the dev > > list - > > > >> I > > > >>> do > > > >>>> not want to happen such a mess once more! > > > > > > > > > > > > > > > > -- > > > > *Anatole Tresch* > > > > Java Engineer & Architect, JSR Spec Lead > > > > Glärnischweg 10 > > > > CH - 8620 Wetzikon > > > > > > > > *Switzerland, Europe Zurich, GMT+1* > > > > *Twitter: @atsticks* > > > > *Blogs: **http://javaremarkables.blogspot.ch/ > > > > <http://javaremarkables.blogspot.ch/>* > > > > > > > > *Google: atsticksMobile +41-76 344 62 79* > > > > > >
