+1 Speak tomorrow in the EG call
Am 08.11.2017 05:04 schrieb "Anatole Tresch" <atsti...@gmail.com>: OK, then I will follow up this thing on Thursday with the guys on the EG. Even is we dont get to be the official implementation, our extensions also will allow us to outstand IMO ;-) 2017-11-07 23:04 GMT+01:00 Oliver B. Fischer <o.b.fisc...@swe-blog.net>: > Hi Anatole, > > I also think we should go this way and try to become the RI of the JSR > 382. It took me some time but I think it would be worth it. > > > Oliver > > > > Am 06.11.17 um 13:27 schrieb Anatole Tresch: > >> Hi all >> >> As you all know I am also actively joining the current configuration JSR. >> Summarizing the state can be summarized as follows: >> >> - The API as taken over from microprofile.io will be taken as a >> starting >> point. We are discussing a few features that also come with Tamaya, >> overall >> I don't think the final API will change drastically. >> - The JSR must select one "official" reference implementation, which >> must be ALv2 based. The JSRs page will reference multiple reference >> implementation though, also including Tamaya. >> - Target is having the JSR finished in 6 months. I think double the >> time >> and we have a realistic timeframe, but let's see ;-) >> >> I will soon add a module in the sandbox, where we implement the new API. >> >> Now thinking about this activities I had a somehow crazy idea: >> >> >> - Originally one objective of Tamaya has been to drive forces to get a >> config JSR up and running. That is now the case. >> - We still would like to have more attention and being the "official" >> RI >> for the config JSR would be an interesting chance to get that. >> - MP as also now the JSR are doing structurally the same thing. We >> have >> some additional features present (some of them like the >> *ConfigurationContext >> *are basically not necessary at all). >> >> So my thinking was, how can best profit from that situation: >> >> - Obviously offer our services to implement the API (already done). >> - But we could go *one step further *by enabling all our extensions to >> work with the new API. If we also get filters as interception >> mechanism >> into the JSR (which I think should be possible and makes sense), >> *building >> all our extensions on top of the JSR instead of the Tamaya API *is a >> no >> brainer. >> - The *ultimate step* would be to make the JSR the center of our >> project, thus basically "deprecating" the former Tamaya APIs. We still >> would support them by a small compatibility-layer, of course >> (implemented >> as extension). >> >> What are the advantages and why this discussion? >> >> >> - Depending on we would agree to support also the ultimate step, I can >> discuss with the JSR EG that Tamaya might get THE official RI. >> - All our extensions and integrations would also work with other >> implementations, which would us put in a similar position that >> Deltaspike >> had for CDI. Given that I expect to have a braoder target in the dev >> <https://maps.google.com/?q=to+have+a+braoder+target+in+ the+dev&entry=gmail&source=g> >> eloper >> community and maybe also attract additional people to join us in a >> later >> step. >> >> WDYT? >> >> J Anatole >> >> >> >> >> >> >> > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E o.b.fisc...@swe-blog.net > S oliver.b.fischer > J oliver.b.fisc...@jabber.org > X http://xing.to/obf > > -- *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* *Speaking at:* [image: JSD_Speaker_2017][image: J-Con 2017 logo][image: JVM Con]
