question is: do you want to push a jsr from it or is it a PoC/other project. In the first case there is no link to apache practise but it is straight forward, in the last you can do it.
Same answer will explicitely show if JSON-P is the one to use for JSon processing or if we dont care Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-06 9:06 GMT+01:00 Anatole Tresch <[email protected]>: > 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*
