Hibernate vs. JPA is also an interesting read: http://stackoverflow.com/questions/9881611/whats-the-difference-between-jpa-and-hibernate Like Tamaya, Apache Commons Config or other config solutions, Hibernate was there before JPA. Its creators were involved as well as many others (even Apache or Novell;-)
Werner On Mon, Jul 18, 2016 at 7:56 PM, Gerhard Petracek <[email protected]> wrote: > before i vote, i would like to hear if there is a real blocker for a > simpler api (besides collections). > > regards, > gerhard > > > > 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] > > >
