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