The 30kByte was the API _plus_ the RI ;) The proposed config-api.jar alone has < 10k.
But again: it is NOT about the size - it is about having a very straight and clean API. LieGrue, strub > Am 19.07.2016 um 20:09 schrieb Werner Keil <[email protected]>: > > I thought Tamaya had already split the two into separate JARs, but it seems > they're both together. > For a desktop/server solution even the ~50k of cache-api look decent, of > course many aspects like transactions were also left out (maybe too vendor > specific, too or there wasn't any time?;-) so whatever a "lean API" still > contains, it may not exceed the 30k of the current JAR. JSR 363 is even a > little smaller and that's the "full" JAR. We do not split out optional > packages by default either, but the spec and API makes clear they're > optional, so should a device with a much smaller footprint require only > "core-api" they can get it (it's offered via a Maven profile) > > Whether that's necessary or not, it's still a long enough way to talk about > standardization. Right now nobody knows what Oracle plans for Java EE 8 and > if vendors will/can follow that or not, so until then I'd say Tamaya is in > a slightly safer and more neutral position where it is till at least the > end of the year. > > Werner > > > On Tue, Jul 19, 2016 at 7:23 PM, Romain Manni-Bucau <[email protected]> > wrote: > >> @Werner: let's agree on API/SPI then see if we spli it or not. That said if >> you look to the proposed design splitting it doesn't make much sense. >> >> >> 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 19:21 GMT+02:00 Werner Keil <[email protected]>: >> >>> In any case for a minimal footprint and constraints, the entire SPI >> module >>> and package should probably be separate/optional. With no references from >>> SPI into API (though some JSRs or other libraries tend to do) only the >>> other way round. >>> >>> E.g. JSR 363 offers the concept of a Unit System (like SI, US, Imperial, >>> etc.) for implementations who like to use it, but the whole SPI is >>> optional, so it's up to users if they retrieve units and quantities via >> the >>> SPI or just stick them on top of a Java enum (we offer a minimalistic PoC >>> implementation that does just that ;-) >>> >>> Werner >>> >>> >>> On Tue, Jul 19, 2016 at 7:12 PM, Romain Manni-Bucau < >> [email protected] >>>> >>> wrote: >>> >>>> This is the point of this design: >>>> >>>> - enable companies to put the solution they want in place (central, in >>> the >>>> app, environmental, ...) >>>> - enable companies to have a CRUD solution on their official impl >> (their >>>> central Source) and integrate it smoothly with tamaya for read part >>>> - enable developers to develop without modifying the code (test sources >>>> added in src/test for instance or scope=test) since they use >>> Configuration >>>> without caring where it comes from >>>> - don't provide developers mocked API: read("namespace:*") >>>> >>>> I perfectly know it can look limiting and you will think "yes but it is >>>> easy to do X", that's sure but you break at least one of these >> statements >>>> which makes the solution specific and then a github project is likely >>>> better. >>>> >>>> Using these limitations you can already go pretty far and nothing >>> prevents >>>> us to provide things on top of that filling the gaps, will just not be >>> part >>>> of the core API everybody will use and agree on. >>>> >>>> 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 18:46 GMT+02:00 Werner Keil <[email protected]>: >>>> >>>>> That is a very good topic to pick up in fact;-) >>>>> >>>>> Mike Keith at a very early stage talked about "CARs" (Configuration >>>>> Archives) >>>>> >>>>> I know from the current and other large enterprise projects with a >> more >>>> or >>>>> less "Cloud" and "Microservice" affine approach, that they often use >> a >>>>> sophisticated series of JARs. Either via Maven or similar >> repositories >>>> and >>>>> subsequent naming or through other distribution methods. >>>>> >>>>> >>>>> More and more solutions use either JSON or a JSON-like format or >> YAML. >>>>> Others use XML not only on the Spring side. >>>>> And you'd even find projects where configuration is loaded from some >>> kind >>>>> of DB. >>>>> >>>>> The problem was evident in a similar way when Otavio proposed a "JSR >>> for >>>>> NoSQL". Given there are so many different types of flavors out there. >>>>> Hibernate OGM (http://docs.jboss.org/hibernate/ogm/5.0/api/) with >>>>> significant contributions by Bean Validation Spec Lead Gunnar Morling >>>>> (according to JavaDoc) managed to get a tiny slim peak to what looks >>>> like a >>>>> giant "iceberg" of API and SPI. Several SPIs, but e.g. >>> DataStoreProvider >>>>> seems to be used across pretty much every implementation. Hard to say >>> if >>>>> the same could be done for so many possible ways of retrieving the >>>>> configuration. >>>>> DeviceMap only got 3 or 4 variations, but essentially you may have >>>> similar >>>>> options. >>>>> >>>>> >>>>> - Plain File system >>>>> - Inside an archive >>>>> - DB >>>>> - Some sort of service call (URL) e.g. RESTful service >>>>> >>>>> Each of those could possibly have variations, Consul, Apache >> Brooklyn, >>>>> Salt, Puppet, etc. to plug into. >>>>> Cheers, >>>>> Werner >>>>> >>>>> >>>>> On Tue, Jul 19, 2016 at 6:22 PM, Mark Struberg >>> <[email protected] >>>>> >>>>> wrote: >>>>> >>>>>> I understand the ratio of not defining the standards for a fixed >> list >>>> of >>>>>> configuration implementations but I struggle to see how the >>> following 2 >>>>>> things can be accomplished: >>>>>> >>>>>> 1.) How do we define a ’standard configuration’ inside a project, >>> e.g. >>>> a >>>>>> jar? >>>>>> >>>>>> 2.) How would you integrate e.g. Consul if there is no SPI to >> plugin >>>> your >>>>>> integration? It would end up being non-portable across containers, >>>> right? >>>>>> Or did I miss something? >>>>>> >>>>>> I need to see an example (sketches) how this would be plugged >>> together >>>>>> from a user aspect. >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>>> Am 19.07.2016 um 17:45 schrieb Anatole Tresch < >> [email protected] >>>> : >>>>>>> >>>>>>> its me again (inline...) >>>>>>> >>>>>>> 2016-07-19 16:34 GMT+02:00 Mark Struberg >> <[email protected] >>>>> : >>>>>>> >>>>>>>> I’ll try to explain this once again. Though this has already >>>>> extensively >>>>>>>> been covered even in the initial incubator proposal ;) >>>>>>>> >>>>>>>> Commons-configuration and DeltaSpike Config / Tamaya do _not_ >>>> overlap! >>>>>>>> >>>>>>>> * commons-configuration is a collection of tools to read and >> write >>>>>> various >>>>>>>> configuration formats from Java. >>>>>>>> * Tamaya aggregates a freely extensible list of such >> configuration >>>>>> sources >>>>>>>> in a well specified (ordered) way to a single uniform solution >>>>> suitable >>>>>> for >>>>>>>> consumption by the user. >>>>>>>> >>>>>>>> To make it clear: Tamaya is the end-user facing API + the >>>> integration >>>>>> SPI. >>>>>>>> commons-configuration could be used in custom ConfigSources to >>>>> leverage >>>>>>>> various configuration formats. >>>>>>>> >>>>>>> >>>>>>> - >>>>>>> > that is the reason, why ultimately speaking even the handling >> of >>>> an >>>>>>> ordered list of property sources is a design decision, which is >>> more >>>>> than >>>>>>> questionable if Tamaya's API should already handle it. Providing >> it >>>>> such >>>>>> a >>>>>>> mechanism as an extension, definitively makes sense, unless we >>> would >>>>>>> directly reuse DS, which would be possible in such a case ;) >>>>>>> -> This also allows e.g. in case of unit test >>>>> mocking/recording/replying >>>>>>> etc. to configure/use any kind of Configuration (e.g. a >> thread/test >>>>>>> isolated JUnit configuration mocker) or simply providing a Java >>>>> delegate >>>>>> to >>>>>>> etcd/consul/zk or whatever system. Not providing any kind of >>>> mechanism, >>>>>> but >>>>>>> the API also makes us less vunerable to discussions about how >>>>>> configuration >>>>>>> should be organized, which ultimately is the main issue, why >>>>>> standardizing >>>>>>> it is so difficult. So from a political perspective it may be an >>>>>> advantage >>>>>>> NOT to define the mechanisms behind, but only provide the main >>>>> mechanism >>>>>> to >>>>>>> access it, the API. Given use cases such as observing, access >>>> control, >>>>>>> mocking, recording and replying an additional filter/post >>> procerssor >>>>>>> mechanism could be useful as well: >>>>>>> >>>>>>> interface ConfigFilter{ >>>>>>> Configuration filter(Configuration config); >>>>>>> } >>>>>>> >>>>>>> But that IMO definitivly is it. Given that I think we can easily >>> let >>>>> the >>>>>>> configuration implementation details being solved by other >>>> frameworks. >>>>>> E.g. >>>>>>> DS can easily be used as source, similarly to Spring >> Configuration, >>>>> OSGI >>>>>>> ConfigAdmin etc ;) >>>>>>> >>>>>>> Similarly we can also provide such a simple API in multiple >>> languages >>>>>> such >>>>>>> as Golang, python, Java and more (as extensions), since it is so >>>>>>> straightfroward ;) and maybe provide a common REST API on top of >> it >>>> as >>>>>>> well... Just to give you some ideas beside the Java world ... >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regarding ‚enhanced Properties‘. That is actually not that far >> away >>>>> from >>>>>>>> what it is! >>>>>>>> The difference is that a ConfigSource has a name (for >>>>>> debugging/analysis) >>>>>>>> and most important: an ordinal number for sorting. >>>>>>>> And the ‚Configuration‘ interface is basically a way to merge n >> of >>>>> those >>>>>>>> Properties together. >>>>>>>> >>>>>>>> Is this part clear now? >>>>>>>> >>>>>>>> If so, let’s please come back to Anatoles proposal and my >>> question: >>>>>>>> If we only have a user facing API but no SPI, how would someone >>>> plugin >>>>>>>> e.g. his default-config into the application? >>>>>>>> >>>>>>> >>>>>>> See above and think on the political aspects ;) I think it would >>>>>> increase >>>>>>> the chance for having a JSR quickly. Definitivly we can discuss >>> this >>>>> kind >>>>>>> of minimal API at this JavaOne and see how the feedback looks >>> like... >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *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* >>>>>> >>>>>> >>>>> >>>> >>> >>
