Let speak about the api. Well decide after when complete in terms of feature/design. If we can stay j7 great otherwise if we have real reasons it is good as well. Le 29 nov. 2014 22:00, "Anatole Tresch" <[email protected]> a écrit :
> 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* >
