+1 John expressed with yet another example (I heard of Archaius at JavaLand where the speaker also mentioned Tamaya, so there's recognition even by those who are not actively involved here;-) what I also did both in a brief reply to Mark himself and other channels like Microprofile.
A JSR is rarely just a single framework or project only changing its package name. JSR 363 was probably one of the few exceptions because it already had a long history of standardization efforts (JSR 108 followed by 275) under its belt. And yet we parked it in an open source project ( unitsofmeasurement.org) for about 5 years before we saw the time right for a JSR in this area and also found corporate contributors as EG member and Spec Lead to help. Anatole did a lot of legwork and canvassing already trying to find those in the first place. Both Oracle (who had initially raised the idea and Mike Keith spoken about it in places as far as India) an Red Hat told him they had no resources at the time. Which is part of the reason why Tamaya and Apache ended up as the best place to gather momentum and a community behind it. The idea always was a possible standard based on what's developed there plus other aspects, be it Commons Config, DeltaSpike or Spring Config. Werner On Mon, Jul 18, 2016 at 1:28 PM, John D. Ament <[email protected]> wrote: > Well, we should probably start with a discussion and not just a vote, > though I do applaud your efforts. > > To me, Tamaya's core is pretty solid and if you're using that you have a > pretty solid framework. There's also a pretty broad suite of extensions > that either add 1. core functionality or 2. integrations on top of other > tooling. To me, 1 is the nice to have part and 2 is the implementation > specific feature set that maybe can be split out at a later point. > > Tamaya so far to me has run into issues around documenting how some of the > extra features work. Its hard to understand from a user's standpoint. > Running into bugs as well, I've tried prodding the PPMC a bit into answer > community questions a bit more. > > I would love to see a JSR be born based on not only Tamaya, but other tools > like Netflix Archaius, Don't forget the purpose of a JSR is to standardize > an idea that is common across many tools. > > I would vote A1 and have someone reach out to other providers to see about > starting to work on A2. The extra features I would vote as a B3, and > perhaps even recommend that we move extensions out into its own git repo. > > John > > On Mon, Jul 18, 2016 at 6:46 AM Mark Struberg <[email protected]> > wrote: > > > Good Morning! > > > > Continuing where we left on Friday... > > > > It seems we have quite an expectation mismatch when it comes to the > > fundamental goals of Tamaya. > > > > > > When we started the incubation proposal we quickly became aware that the > > initial code [1] was a bit too inflexible and large. So we ALL decided to > > simply collect information about all the different approaches out there > and > > review how good they are. > > After having done this we decided to go into the direction of what > Gerhard > > and I wrote for DeltaSpike back in 2011[2]: A system of ConfigSources > which > > get sorted based on their ordinal. > > Of course the intention was to improve that and push hard for a JSR. > > Because otherwise we could have simply continued to work on that stuff in > > DeltaSpike. > > > > This was also discussed with the DeltaSpike community. DeltaSpike was > even > > cool to replace their own solution with Tamaya IF it delivers! But that > did > > not yet happen. And so the DS config mechanism got improved and now > > contains even more nice features. > > So in a way Tamaya basically forked DeltaSpike, and it's funny that some > > people now accuse me that I did fork Tamaya. Please note that _neither_ > is > > my personal view and I'm totally fine with Tamaya now using the same > > approach as DeltaSpike. It's always a give and take in OpenSource - and > > especially if the teams overlap for a good bit. > > > > More than a year ago we had some discussions that we should heavily clean > > up the Tamaya API and really keep it at a bare minimum level. Afair > > Gerhard, Romain, Reinhard and I supported that direction. Nonetheless > there > > was opposition to that approach and despite we all seemed to agree on a > > cleanup that never happened - the code actually even grew. So some people > > silently went inactive in Tamaya because they felt there is not enough > > common ground. > > > > Fast Forward a year. > > > > After a discussion with various EG members I came back to Tamaya last > week > > and looked how far it came. > > In my personal opinion it is a good bit too much in the API. > > There is still no TCK and no spec wording (Although there are good docs, > > but a spec paper still has a different approach). And the api is imo a > tad > > beyond being very simple and easy to use. > > > > That is the reason why I quickly took the bits Gerhard and I (+ other > > small contributors) wrote in DeltaSpike and even further streamlined it. > > > > * In the minimal version [3] there are 5 interfaces now: ConfigProvider, > > Config, ConfigSource, ConfigFilter, ConfigSourceProvider > > (that's the DeltaSpike terms, replace ConfigSource with PropertySource in > > Tamaya; the rest is basically the same) > > Even PropertyFileConfig will most probably be removed as it is easy to > > write yourself. > > > > * In a slightly enhanced version I added Gerhards TypedResolver idea and > > improved it [4]. This is now 7 interfaces: ConfigProvider, Config, > > ConfigSource, ConfigFilter, ConfigSourceProvider, ConfigValue and > Converter > > > > This allows for things like > > > > ConfigValue<Integer> reloadAfterCfg = > > ConfigProvider.getConfig().access("myproject.mydb.reloadAfter") > > .as(Integer.class) > > .withDefault(1000) > > .cacheFor(5, TimeUnit.MINUTES) > > .evaluateVariables(true) > > .withLookupPath(config.getValue("myproject.dbvendor"), projectStage); > > > > And later use > > reloadAfterCfg.getValue() > > whenever that value is needed. So this even supports dynamic mutable > > access to configured values without trashing the config system. > > And all that with 7 straight forward interfaces! > > > > > > > > To come to a conclusion [VOTE]: > > > > A: What do we like to provide in Tamaya? > > > > A.1.) Just another config framework? > > > > A.2.) A candidate for a Java Config JSR? > > > > > > B: Do the other 20 classes/interfaces in Tamaya really provide such a > huge > > benefit that it absolutely makes sense to keep them? > > > > B.1.) No, it's just too much and all the additional features can be built > > on top of the very basic 7 classes approach anyway. Let's go for that. > > > > B.2.) Yes, because the simple 7interfaces approach misses the following > > features and usecases:... > > > > B.3.) The additional stuff is not absolutely necessary but nice to have. > > We might split them into a very basic part which we propose as JSR and > > another Tamaya specific part with additional features on top of it. > > > > > > The VOTE is open for 72h with lazy consensus. > > > > My personal VOTE is A.2 and B.3 > > > > > > Hope those bits help to understand my frustration a bit. > > > > LieGrue, > > strub > > > > > > > > [1] > > > https://github.com/apache/incubator-tamaya/tree/cf59ebbd1b4ac03fb366b49268fc57c1a00f5616/api/src/main/java/org/apache/tamaya > > > > [2] > > > https://github.com/apache/deltaspike/commit/fb0131106481f0b9a8fdc13b9879a5482219c736 > > > > [3] > > > https://github.com/struberg/javaConfig/tree/master/api/src/main/java/javx/config > > > > [4] > > >
