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 >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>
