> generic API yet - or it means you need to put write method there as well > and I’m not sure we are ready for that or want that. Please no write() methods on the Config or ConfigSource ;)
The reason why we introduced getProperties() in CODI (and later kept it when moving to DeltaSpike) is that you can create a page which portably lists all configured values and from which ConfigSource they effectively come. This is really important for bigger projects where the Ops team is in charge for tweaking the configuration according to their needs. DevOps does still not exist in _many_ of those companies :( But again: Anatoles proposal does not contain any ConfigSource nor any other SPI at all. Now the question is whether this is ok or if we need the SPI part? LieGrue, strub > Am 19.07.2016 um 14:19 schrieb Romain Manni-Bucau <[email protected]>: > > 2016-07-19 13:57 GMT+02:00 Mark Struberg <[email protected]>: > >> Thanks Anatole, It’s a start. >> >> But this only covers the consumer part, or did I miss something? >> What about the SPI part? >> >> Do you think we can live without a way to declare where the configuration >> comes from? >> Would this be totally up to the container vendor? >> How to provide default configuration inside e.g. a jar? >> >> @Romain: yes, I also think get(String) is enough, rest is probably sugar. >> The getProperties() actually makes mostly sense on the ConfigSources (e.g. >> for an admin/control page) but probably not on the final Configuration >> instance. >> >> > Kind of agree but for me getProperties() depends the source and each source > can get its own admin "repository" so I think it doesn't belong to a > generic API yet - or it means you need to put write method there as well > and I'm not sure we are ready for that or want that. > > >> txs and LieGrue, >> strub >> >> >>> Am 19.07.2016 um 13:38 schrieb Romain Manni-Bucau <[email protected] >>> : >>> >>> Ok for ConfigException, ConfigProvider with some rework (see end of the >>> mail) is ok however I think that: >>> >>> - Configuration (as a core API) shouldn't get more than get(String). The >>> "or default" is sugar we'll add on top of that anyway and getProperties() >>> implies you can list all entries which can not be possible so I wouldn't >> do >>> it in the main core part (DS did it for historical reasons and I think >>> today it is not the best it could have done) >>> - I tend to think Filter and Source can be part of the core cause >> otherwise >>> you have an entry supplier without any way to provide values. >>> >>> >>> Then about provider: what about just applying bean validation model >> blindy >>> first (provider to load a factory to create through a builder API or >>> through default loading mecanism an instance - of Configuration for us)? >> I >>> don't think we can get rid of the provider layer cause it will likely use >>> ServiceLoader - even in OSGi since it will be part of the impl so fine - >>> and the provider will then use what is adapted to its env to load other >> SPI >>> like sources/filters. >>> >>> So it would make a core of (feel free to change name): >>> >>> - Configuration { >>> String get(String); >>> static Configuration buildDefaultConfiguration() { >>> >> byProvider(...loadDefault()...).withSources(...loadDefaults()...).withDeciphers(...loadDefaults()...).build(); >>> } >>> static BootConfig byProvider(String); >>> } >>> - ConfigurationProvider { >>> Configuration build(BootConfig) >>> } >>> - BootConfig { >>> withSources(sources...); >>> withDeciphers(filters...); >>> Configuration build(); >>> } >>> - ConfigurationSource { String get(String); String name(); } // but don't >>> impl Configuration for future >>> - ConfigurationDecipher { String decipher(String); String name(); } >>> >>> >>> wdyt? >>> >>> >>> >>> 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-19 13:18 GMT+02:00 Werner Keil <[email protected]>: >>> >>>> Sounds like a plan. >>>> >>>> Not sure, if a "general" top level configuration type specialized for >>>> String allows extending it in another model without some restrictions, >> but >>>> if the java.util.Properties like get(String) is of minimalistic use, >> e.g. >>>> where it's backed by "good old Properties" anyway why not. Extending it >> it >>>> with a flexible type-system would still be possible. >>>> >>>> Supplier<String> sounds Java SE 8, so in an API that works both in Java >> SE >>>> 6/7 or Java ME 8 that cannot exist. >>>> >>>> If a type like ConfigurationProvider is optional, then it would be >> better >>>> to put it to another package. Makes building smaller modules easier >> IMHO, >>>> otherwise you probably have to use filtering and "Maven magic" to ensure >>>> only the mandatory or core types are packaged for a "minimal" profile or >>>> situation while everything is built for a "full" scope. >>>> >>>> Werner >>>> >>>> >>>> >>>> On Tue, Jul 19, 2016 at 12:39 PM, Anatole Tresch <[email protected]> >>>> wrote: >>>> >>>>> For me a point is that I would like to see the API being complete, >>>> meaning >>>>> all I need is the API to get a Configuration. Using Java 8 I don't need >>>> it, >>>>> so I can provide the ConfigurationProvider for Java 7 only. >>>> ConfigOperator >>>>> and -Query are only there for Java 7, they easily vould be removed from >>>> the >>>>> API as well. >>>>> But talking about minimal: a*lso the idea of organizing configuration >> as >>>>> property sources is already a design decision the API should not care >>>> about >>>>> IMO*. So being really minimal, we need: >>>>> >>>>> - Configuration (interface) >>>>> - ConfigException (exception) >>>>> - ConfigurationProvider (optional) >>>>> >>>>> The key here is Configuration. We agree IMO to provide *single* key >>>> access >>>>> for String values. IMO people also expect access to non-String values, >>>> but >>>>> this must not be part of the core Configuration interface since it >> could >>>>> easily be added as a facade functionality for example, so it can be >>>>> realized as an extension module! >>>>> Accessing a Map<String,String> of properties IMO, and also from user >>>>> feedback, is a wanted functionality. In most cases also the result can >> be >>>>> well calculated and further functionality added on top that most people >>>>> expect from a Configuration solution. This is also what we have done in >>>> the >>>>> current source tree (see tamaya-functions module). >>>>> >>>>> So my proposal would be: >>>>> >>>>> - reduce the API to these 3 artifacts (including ConfigProvider - it >>>>> doesnt hurt and makes migration from Java 7 to 8 much easier). >>>>> - Remove type support from Configuration, it can be added in a >>>> separate >>>>> module >>>>> , which is not too much change needed). >>>>> . >>>>> - discuss how the ConfigurationProvider loads the Configuration >>>>> instance to be returned (service loader, OSGI service). >>>>> - move all the rest of artifacts into separate modules. This also >>>>> includes the DS inspired parts of PropertySource handling currently >> in >>>>> the >>>>> core module. >>>>> >>>>> >>>>> People already using deltaspike can easily plugin in the DS logic >> without >>>>> having to rewrite anything and start using the new API. In CDI >>>>> Configuration can be determined from using the CDI context (os >> something >>>>> else in stages, where CDI is not yet loaded). Same story for Spring and >>>>> more. >>>>> >>>>> This is basically what I proposed in the* tamaya-next branch*: So our >>>>> complete core API fits into half a page! >>>>> >>>>> public interface Configuration { >>>>> String get(String key); >>>>> default String getOrDefault(String key, final String >> defaultValue){...} >>>>> default String getOrDefault(String key, Supplier<String> >>>>> defaultValueSupplier){...} >>>>> Map<String,String> getProperties(); >>>>> } >>>>> public final class ConfigurationProvider { >>>>> [...] >>>>> Configuration getConfiguration(){ >>>>> // tbd >>>>> } >>>>> } >>>>> public class ConfigException extends RuntimeException{ >>>>> private static final long serialVersionUID = -5886094818057522680L; >>>>> public ConfigException(String message){ >>>>> super(message); >>>>> } >>>>> public ConfigException(String message, Throwable t){ >>>>> super(message, t); >>>>> } >>>>> } >>>>> >>>>> J Anatole >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2016-07-19 9:08 GMT+02:00 Werner Keil <[email protected]>: >>>>> >>>>>> tamaya-api-0.2-incubating.jar is just 30 kb right now. >>>>>> While the exact set of methods is questionable in the "design study" >>>>> (just >>>>>> leave it as that and thanks to EC members like myself or Ben there's >> no >>>>>> further damage done by the way it was presented, we're not talking >>>> about >>>>>> JCP aspects here now ;-) a minimalistic approach may leave >>>> Configuration >>>>>> and ConfigException pretty much the only core elements. Not even sure >>>>> about >>>>>> the *Provider. As the name suggests it could be in an SPI, take JCache >>>>>> (where only its Caching static facade mixes the two and makes clean >>>>>> separation impossible, CacheProvider is in an SPI package though) >>>>>> >>>>>> *Operator and *Query feel a bit redundant and both can be seen as >>>>> optional. >>>>>> Especially for implementations based on Java 8 one could probably >> stick >>>>> to >>>>>> Function<Configuration, Configuration> or similar to accomplish that. >>>> If >>>>>> Tamaya needs a Java 7 compatibility layer (it'll take years before >>>>>> especially the Enterprise sector will fully adopt even Java SE and EE >>>> 7, >>>>> I >>>>>> work there all the time and see what's used;-) then it could be in a >>>>>> different package/jar, but doesn't have to be in a core API. >>>>>> >>>>>> Cheers, >>>>>> Werner >>>>>> >>>>>> >>>>>> On Tue, Jul 19, 2016 at 3:57 AM, Mark Struberg >>>> <[email protected] >>>>>> >>>>>> wrote: >>>>>> >>>>>>> Then see it as the smallest possible core. It has only 30 kByte >>>> (api+RI >>>>>>> jars). >>>>>>> It even works on ME or Android. >>>>>>> >>>>>>> LieGrue, >>>>>>> Strub >>>>>>> >>>>>>>> Am 19.07.2016 um 01:00 schrieb Werner Keil <[email protected] >>>>> : >>>>>>>> >>>>>>>> We're not talking about the API when it comes to Spring, OSGi or >>>> even >>>>>> CDI >>>>>>>> support. Same for say a YAML module, etc. >>>>>>>> Those are implementation specific. >>>>>>>> >>>>>>>> The more modular and fine-grained the API (of Tamaya) can get, the >>>>>>> better. >>>>>>>> >>>>>>>> CDI has to learn that with V2 only, but for relatively new JSRs or >>>>>> modern >>>>>>>> projects it should be considered right from the start. >>>>>>>> The most basic core API may or may not work even on Java ME >>>> Embedded. >>>>>>>> JSR 363, which has a core of only 4 mandatory core types plus 3 >>>>>>> exceptions. >>>>>>>> If put in a separate JAR those would only take around 5k. Fits even >>>>> the >>>>>>>> smallest Java ME device out there. You may not always be able to >>>> cut >>>>>>> things >>>>>>>> as small in "Server Land" but getting the idea and trying to be >>>>> modular >>>>>>>> even before the JDK starts to enforce that with Java 9 is the right >>>>>>>> approach. >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 18, 2016 at 11:13 PM, Romain Manni-Bucau < >>>>>>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Le 18 juil. 2016 23:04, "Werner Keil" <[email protected]> a >>>>>> écrit : >>>>>>>>>> >>>>>>>>>> Tamaya already works with e.g. Spring despite Spring Framework >>>>>> offering >>>>>>>>>> Config functionality of its own;-) >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes but libs cant rely on spring config api without bringing back >>>>>> spring >>>>>>>>> core >>>>>>>>> >>>>>>>>>> So as there are other config solutions at Apache like Commons >>>>> Config, >>>>>>>>>> exclusing CDI because DeltaSpike already uses it sounds odd. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Commons config has no link afaik since it provides nice low level >>>>> impl >>>>>>> but >>>>>>>>> no good end user api/integration. It is also too opiniated to be >>>>> good >>>>>>> for a >>>>>>>>> spec since it has a lot of core methods making it hard to >>>> integrate >>>>>> with >>>>>>>>> all frameworks without limitations. >>>>>>>>> >>>>>>>>> That is why tamaya core should be minimal IMO. >>>>>>>>> >>>>>>>>>> There are even Apache projects like Tapestry that still offer >>>> their >>>>>> own >>>>>>>>> DI >>>>>>>>>> mechanism beside a JSR 330/CDI one, so I hope you're not >>>> suggesting >>>>>>>>> Tamaya >>>>>>>>>> should do the same just to "avoid" DeltaSpike?;-O >>>>>>>>>> >>>>>>>>> >>>>>>>>> I'm saying that tamaya core should be light enough to work with >>>> any >>>>>>> context >>>>>>>>> impl and never conflict with them, ie not implementing another >>>>>> context, >>>>>>> ie >>>>>>>>> providing built Config but not store them itself. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jul 18, 2016 at 10:53 PM, Romain Manni-Bucau < >>>>>>>>> [email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Trying to get back on track... >>>>>>>>>>> >>>>>>>>>>> If Tamaya targets CDI it will compete in a useless manner with >>>> DS >>>>> or >>>>>>>>> any >>>>>>>>>>> specific config API, if it targets contextuality it will with >>>> any >>>>>> IoC, >>>>>>>>> if >>>>>>>>>>> it targets coercing it will as well with one or both of previous >>>>>>>>> points. >>>>>>>>>>> >>>>>>>>>>> So IMO Tamaya API should be as Mark explained about handling >>>>> sources >>>>>>>>> and >>>>>>>>>>> filters to build on Config which can provide string access - and >>>>> not >>>>>>>>>>> properties cause it shouldnt be listable by default IMO. >>>>>>>>>>> >>>>>>>>>>> In term of API design I would align it on bval - a factory with >>>> a >>>>>>>>> builder >>>>>>>>>>> or a default loading to get a Config. It is core for me. Mark >>>>> likes >>>>>> to >>>>>>>>>>> count classes: factory + config + provider + source + source >>>>>> provider >>>>>>> + >>>>>>>>>>> filter (we can merge few of them using j8, not sure it is good >>>> but >>>>>>>>> would >>>>>>>>>>> work). >>>>>>>>>>> >>>>>>>>>>> Once we agree on that we will have to discuss on top of that: >>>>>>>>>>> >>>>>>>>>>> - integrations >>>>>>>>>>> - injections (injection points vs proxy Bean) >>>>>>>>>>> - coercion >>>>>>>>>>> - default impls >>>>>>>>>>> - .... >>>>>>>>>>> >>>>>>>>>>> But making the API small, strong and usable by all is important >>>>> IMHO >>>>>>>>>>> >>>>>>>>>>> Le 18 juil. 2016 22:41, "Werner Keil" <[email protected]> a >>>>>> écrit >>>>>>>>> : >>>>>>>>>>> >>>>>>>>>>>> Sorry to dissapoint you, but I was involved at least in Tamaya >>>>>> before >>>>>>>>>>>> Anatole even proposed it. >>>>>>>>>>>> I was nearly asked to give the presentation on what later >>>> became >>>>>>>>> Tamaya >>>>>>>>>>> by >>>>>>>>>>>> Mike Keith when he was stuck in heavy Monsoon rain at GIDS >>>>> 2011;-) >>>>>>>>>>>> >>>>>>>>>>>> I know what Commons Config, Tamaya or DeltaSpike can be used >>>> for. >>>>>> And >>>>>>>>>>>> helped clients who found e.g. DeltaSpike too complex and >>>>> overloaded >>>>>>>>> by >>>>>>>>>>>> contributing to their in-house CDI-based configuration >>>> framework >>>>>>>>>>> "inspired" >>>>>>>>>>>> by it. So Tamaya isn't the only example of API that some find >>>>> "too >>>>>>>>>>> much"... >>>>>>>>>>>> >>>>>>>>>>>> Werner >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jul 18, 2016 at 10:08 PM, Mark Struberg >>>>>>>>>>> <[email protected] >>>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> It seems you do not yet understand the mechanics behind >>>>> DeltaSpike >>>>>>>>> and >>>>>>>>>>>>> Tamaya. Let me elaborate: Properties (and commons-config1&2 as >>>>>> well >>>>>>>>> for >>>>>>>>>>>>> that matter) only handle information from a SINGLE file. >>>>>>>>>>>>> >>>>>>>>>>>>> Whereas the ConfigSource approach abstracts that into an >>>> ordered >>>>>>>>> stack >>>>>>>>>>> of >>>>>>>>>>>>> _multiple_ such 'sources'. And such a >>>>> ConfigSource/PropertySource >>>>>>>>> also >>>>>>>>>>>>> doesn't need to be a single property file. It can be anything >>>>>> which >>>>>>>>>>> gives >>>>>>>>>>>>> access to configuration information. >>>>>>>>>>>>> >>>>>>>>>>>>> So yes, it should imo be as easy as property files - even >>>>> easier. >>>>>>>>> But >>>>>>>>>>> it >>>>>>>>>>>>> is not a _single_ file but many of them. And not only property >>>>>>>>> files >>>>>>>>>>> but >>>>>>>>>>>> a >>>>>>>>>>>>> freely extensible bunch of different such configuration >>>> sources! >>>>>>>>>>>>> >>>>>>>>>>>>> I hope you _now_ see the huge difference. >>>>>>>>>>>>> Regarding type-safety: I already wrote that twice: check out >>>>>>>>>>> ConfigValue. >>>>>>>>>>>>> (copying the example again): >>>>>>>>>>>>> >>>>>>>>>>>>> --- >>>>>>>>>>>>>> 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()--- >>>>>>>>>>>>> >>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>> strub >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Monday, 18 July 2016, 21:53, Werner Keil < >>>>>> [email protected] >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> To consider possible simplification and common denominators, >>>> it >>>>>>>>> seems >>>>>>>>>>>>> good to have a look at Tamaya's base interface: >>>>>>>>>>>>> >>>>>>>>> >>>>> http://tamaya.apache.org/apidocs/org/apache/tamaya/Configuration.html >>>>>>>>>>>>>> and >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> https://commons.apache.org/proper/commons-configuration/apidocs/org/apache/commons/configuration2/ImmutableConfiguration.html >>>>>>>>>>>>>> >>>>>>>>>>>>>> they have at least some very basic methods in common. Leaving >>>>> the >>>>>>>>>>> order >>>>>>>>>>>>> of key or type aside. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> In your proposed Config interface I only saw a >>>>>>>>>>>>>> String get(String) method, but for that sorry, we could just >>>>>> stick >>>>>>>>> to >>>>>>>>>>>> the >>>>>>>>>>>>> good old Properties and forget about the whole thing ;-| >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> A default or convenience method (what Commons Config 2 calls >>>>>>>>>>>> getString()) >>>>>>>>>>>>> why not, but without type-safe yet extensible getters, there >>>> is >>>>>>>>> little >>>>>>>>>>>>> value to create a new API with more or less the same value >>>>>>>>> (literally) >>>>>>>>>>>> than >>>>>>>>>>>>> java.util.Properties. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I know you're on the CDI EG, other than that, not sure, >>>> which >>>>>>>>> others >>>>>>>>>>>>> (according to JCP.org, not mailing lists or other forms of >>>>>>>>>>> contribution) >>>>>>>>>>>>>> Being on both sides (EG and EC) in many cases, I am used to >>>>>>>>> question >>>>>>>>>>>> JSRs >>>>>>>>>>>>> and their Spec Leads, so it's not bad if this happens before >>>> any >>>>>> of >>>>>>>>>>> that >>>>>>>>>>>>> was filed or sonsidered towards a JSR. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Although there had been 2 attempt (one even by Adam Bien at a >>>>>> very >>>>>>>>>>> early >>>>>>>>>>>>> stage of his efforts in the JCP) JSR 377 is an example for a >>>>>>>>> seemingly >>>>>>>>>>>>> premature JSR proposal. And unless Andres does some "miracle" >>>> it >>>>>>>>> may >>>>>>>>>>>> likely >>>>>>>>>>>>> be shut down by the EC with the next Renewal Ballot. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So JCP.next introduced a few measures to avoid "neverending >>>>> JSRs" >>>>>>>>> like >>>>>>>>>>>>> 107 or 310 now, but sometimes it isn't a bad thing to wait or >>>>> file >>>>>>>>> it >>>>>>>>>>>> based >>>>>>>>>>>>> on experience by one or several Open Source projects. >>>> Hibernate >>>>>> was >>>>>>>>>>> one, >>>>>>>>>>>>> but considering the JPA RI is based on TopLink (now >>>> EclipseLink) >>>>>> it >>>>>>>>>>>>> certainly isn't the only project behind what became JPA >>>> either. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Werner >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jul 18, 2016 at 9:15 PM, Mark Struberg >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Yes Werner, we know. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But nonetheless Hibernate managed to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> a.) get the spec on the ground pretty efficiently >>>>>>>>>>>>>>> b.) implemented the JPA specification on top of their own >>>>> logic >>>>>>>>> in a >>>>>>>>>>>>> timely fashion. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As you know I'm contributing to a number of specifications >>>> as >>>>> an >>>>>>>>>>>>> _active_ JCP EG member myself for many years now, so I really >>>>> know >>>>>>>>> all >>>>>>>>>>>> this >>>>>>>>>>>>> stuff! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On the original topic: if I say '5 interfaces' than those >>>>> don't >>>>>>>>> need >>>>>>>>>>> to >>>>>>>>>>>>> be exactly the ones I proposed. I also don't care whether we >>>>> call >>>>>>>>> them >>>>>>>>>>>>> ConfigSource or PropertySource (as example). All I like to do >>>> is >>>>>> to >>>>>>>>>>>> review >>>>>>>>>>>>> and clean up the API. After all this is a community decision. >>>>> If a >>>>>>>>>>>> majority >>>>>>>>>>>>> of Tamaya committers say I'm nuts and the current API is fine, >>>>>> then >>>>>>>>> be >>>>>>>>>>>> it. >>>>>>>>>>>>> Otoh if the majority is to do the cleanup then we should do it >>>>>>>>>>> properly. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>>> strub >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Monday, 18 July 2016, 20:55, Werner Keil < >>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Anatole Tresch* >>>>> PPMC Member Apache Tamaya >>>>> JCP Star Spec Lead >>>>> *Switzerland, Europe Zurich, GMT+1* >>>>> *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * >>>>> *Twitter: @atsticks, @tamayaconf* >>>>> >>>> >> >>
