Haven't played with it myself, but found it quite unfortunate, JSR 107 had to "reinvent" its configuration subsystem once again. Probably one of the worst examples for getting a JSR done (it took more than 10 years) but the configuration subsystem also looks type-safe: http://static.javadoc.io/javax.cache/cache-api/1.0.0/javax/cache/configuration/package-frame.html
Yet, the 6 base elements of http://tamaya.apache.org/apidocs/org/apache/tamaya/package-frame.html don't exceed even what's only a byproduct of JCache in number of API items. The SPI could likely be trimmed down a bit: http://tamaya.apache.org/apidocs/org/apache/tamaya/spi/package-frame.html Especially a "universal Service Provider" along the lines of JSR 354 could be done differently as we explored and succeeded with JSR 363: http://unitsofmeasurement.github.io/unit-api/site/apidocs/javax/measure/spi/ServiceProvider.html Probably end up smaller than all of JCache ;-) The rest IMHO are goodies and extensions. The Cache RI is also a rather small "bare bone" reimplementation and they did not take all of EHCache ( http://www.ehcache.org/apidocs/2.6.9/ scary, eh, not so different from Tamaya ? ;-) Regards, Werner On Mon, Jul 18, 2016 at 6:38 PM, Mark Struberg <[email protected]> wrote: > 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 > > >
