Though having a skeleton of almost every aspect is something e.g. JSR 377 is badly missing despite being created already, there was more than the package names wrong or missing, so a first shot nothing more.
A spec without a proper Spec License only to mention. Unless Red Hat (the only Spec Lead ever to somehow get that kind of dual-licensing tolerated or bothered doing with the Spec, not the other SW artifacts) suddenly had a change of heart and did decide to run as Spec Lead this wouldn't work for any individual. IBM and others did not do so either. And a "TCK" that's merely simply JUnit tests making assumptions about particular config values, sorry but having just finalized one that also uses aspects of the CDI TCK (e.g. regarding profiles, but I slightly improved some bits) I can tell you it should at most be considered a src/test folder of the impl module in that form... Again, let's focus on Tamaya, when the time comes it also requires a few people in the EG. The time of "Two and a Half Experts" in JSRs like 310 is certainly over. It also would not have become java.time without Oracle's help and constructive input by a few others. Cheers, Werner On Tue, Jul 19, 2016 at 10:08 PM, Mark Struberg <[email protected]> wrote: > 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* > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
