if you do 7 then you can merge core and api since another vendor providing another implementation will not work with all other modules. This can imply few duplication - can be workaround with mvn - but this is mandatory IMO.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-06 8:41 GMT+01:00 Oliver B. Fischer <[email protected]>: > Important questions ;-) See inline... > > Am 04.01.15 um 12:50 schrieb Anatole Tresch: >> >> >> 1. it should implement the api/spi for simple se usage. > > +1 > >> 2. it should provider enough logic to provide the minimal building blocks >> so a user could build a minimal config system. > > +1 >> >> 3. said this I would expect that properties configs are supported ootb as >> a format. > > +1 >> >> 4. I would expect that adding a propertysource is basically a one liner if >> the file is in the cp or a file. > > +1 >> >> 5. I would expect that core helps me defining my location declaratively. >> users dont care about resource loading details, they expect the lib to >> handle that ootb. > > +1 >> >> 6. I would expect that the mechanisms provided are extendible, so with >> adding additional modules the api basically still feels the same. Given that >> abstractions must be defined in the api or in core. > > In core. See my mail from today. I encountered the same propblem in the JSON > module. It is not a part of the API IMHO since Tamaya is only a > imlementation of the API. But to avoid code duplication and diverging > solutions for the same problem it must be provided by core. >> >> 7. I dont think extension modules must rely on the api only (if that would >> be a decision we might have to discuss if the api may define more things). >> My idea is that tamaya is a combinable set of modules that as a whole can be >> tailored to the many different facets required. Constraining modules on api >> deps will probably lead to much duplications, but lets see... > > Following this approach would allow us to combine extension (or extra) > modules with implementations of a different vendor? A Tamaya extension must > be allowed to depend on core. Otherwise we will have the problems addressed > by 6 > > >> 6 and 7 are things to be argued about I think. >> >> If we see core as a supermonimalistic set that is not enough per se for >> all supertrivial usage scenarios I agree I would remove latest additions to >> a separate module. Perhaps this is even the best solution to keep our >> personal hygiene in place ;) >> >> Cheers >> Anatole >> >> - >> Anatole Tresch >> Glärnischweg 10 >> 8620 Wetzikon >> Tel +41 (43) 317 05 30 >> - >> Send from Mobile > > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E [email protected] > S oliver.b.fischer > J [email protected] > X http://xing.to/obf >
