Hi Currently lots of the logic in the modules can be done based on API only. I would try to stay on that track and see how far we get. For me it looks a bit strange that an Apache project tries to prevent dependencies from itself, but it may be wise also from a cohesion perspective to do so. Still we have an option of defining a common additional functionality as module and depend on that module from other modules. Said this we must ensure we minimize that deps nevertheless.
Cheers, Anatole 2015-01-06 8:53 GMT+01:00 Romain Manni-Bucau <[email protected]>: > 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 > > > -- *Anatole Tresch* Java Engineer & Architect, JSR Spec Lead Glärnischweg 10 CH - 8620 Wetzikon *Switzerland, Europe Zurich, GMT+1* *Twitter: @atsticks* *Blogs: **http://javaremarkables.blogspot.ch/ <http://javaremarkables.blogspot.ch/>* *Google: atsticksMobile +41-76 344 62 79*
