It sounds worth considering. Of course there has been effort by Mark, Co-Spec Lead of the JSR and mostly John into Geronimo Config https://github.com/apache/geronimo-config/graphs/contributors
Compared to the codebase and various extension modules (I would not see many as part of the RI, but extensions and an ecosystem around it) Tamaya has https://github.com/apache/incubator-tamaya/graphs/contributors there is less involvement in Geronimo. Since especially John has contributed to both (more LOC in Tamaya) hope he can tell us what he thinks. Tamaya despite incubating also has a couple of commercial users already, while unless TomEE might use it under the hood, Geronimo may not be so widely used in real applications and projects with actual customers. The OSGi support Tamaya demonstrated recently is certainly a plus, but can't say, how important it is for vendors outside IBM/Liberty? I would certainly talk to Emily what she thinks of the OSGi support, and if that's something, OpenLiberty might even use instead of creating its own implementation of JSR 382 (of course that could potentially also be another good RI candidate, it is Open Source now;-) Both options seem possible, either Tamaya was seen as a good RI candidate and also gets used at least by those projects and products that build on top of Geronimo Config or created their own implementation so far, or it could be the OpenWebBeans/Johnzon equivalent at Apache like they do as alternate compatible implementations for CDI or JSON-P/B. Even if Geronimo was considered the ideal RI, Apache is so diverse, that you often have two or more solutions for a particular problem. Werner On Mon, Nov 6, 2017 at 1:27 PM, Anatole Tresch <[email protected]> wrote: > 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 > developer > community and maybe also attract additional people to join us in a later > step. > > WDYT? > > J Anatole > > > > > > > -- > *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] >
