type-safety can be done in as little as 2 interfaces. Check the sample I gave with ConfigValue + Converter. We are then up to 7 classes. Still way below the current Tamaya API
I'm not afraid of features per se. But I'm afraid of features which heavily add weight, are only of limited use and can easily be done on the customer side. Also: the more features we add to the API, the less likely it is to get a JSR done. LieGrue, strub > On Monday, 18 July 2016, 18:13, Oliver B. Fischer <[email protected]> > wrote: > > I would like to target A2 and B2. Why B2: Of course I don't like to stay > in the 90ties and there is are a lot of modern frameworks who provide > such features as type safety and so on. Ok, I could do all this modern > stuff by hand - but I always would like to have a usefull framework. > > In my daily work I need collections and I need type safety. Why are we > so afraid of such usefull features? > > > Oliver > > Am 18.07.16 um 12:46 schrieb Mark Struberg: >> 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] > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > > J [email protected] > X http://xing.to/obf >
