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
