I'd say best we can do @asf is A1 but I'd like to target A2 for "tamaya-core" too
About B: I think we need to define the target more than the #files and keep the smaller API to enable all integrations (spring, CDI, standalone, ...) and environments (standalone, EE, OSGi, fatjars, ...). it will likely tend to join B.1 as a consequence but I would like tl emphasis it is not the way to see it even if the outcome is the same. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> | JavaEE Factory <https://javaeefactory-rmannibucau.rhcloud.com> 2016-07-18 12:46 GMT+02:00 Mark Struberg <[email protected]>: > 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] >
