That is not the question, sorry. A JSR requires an API, a RI and a TCK. You can have a RI that adds as well other functionality. It is definitively not required that a RI strictly ONLY implements the API (see Glassfish and more). So I was thinking of the core part to be minimal, but still offering a minimal set of user features OOTB. And on top of that. a JSR is a complete other story. To think that our solution will go into a JSR 1-1 is not realistic. There will be other experts, opinions and a lot of work. At the end it might be that a new RI is written from scratch (e.g. this happened with JSR 354, where JodaMoney was taken as a start, but we evolved from that rather quickly).
2015-01-06 9:10 GMT+01:00 Romain Manni-Bucau <[email protected]>: > 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* > -- *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*
