Each time I wrote extensions based on a JSR, extension module was only relying on the API which means you can switch the implementation (core) and still use the extensions - that's the case for bval, batchee, johnzon... Otherwise you use a standard implementation but cause of your extension usage you are bound to a particular implementation which means you are no more portable and then it doesnt worth using a standard API - this is what does Weld at the beginning and it just slows down adaption for all the OWB users.
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-06 10:52 GMT+01:00 Anatole Tresch <[email protected]>: > I do not fully agree, things are not so trivial. Vendor lock in is, when > the API is vendor specific, so you don't have a choice at all. If you use > useful features and depend on the modules you have the same vendor > dependency, regardless if its core or a module. You depend on Tamaya. That > is the reason I tend to not be that constraint about the core part. Define > an API, but for all the rest think as a project (but still keep up the > discussions to minimize deps, if an extension can only depend on the API > only, it should so). If you really want to prevent vendor lock in you have > to declare it as part of the API. Given that you have a natural API design > conflict. Keeping the API minimal is nice, but increases possible vendor > lockin. Building the API to big, makes it difficult to implement, so you > will probably not have much choice on the vendors available. But the core > abstraction for vendor independence is the API IMO, NOT core. > > > 2015-01-06 10:31 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> This is fully the question Anatole. If you start writing extensions >> based on your "RI" - implementation actually - then you don't extend >> your API but your overall product. This is called vendor locking and >> it is the worse thing you can do based on a JSR. This doesn't prevent >> you to write extension but based on the API and not the core. >> >> >> Romain Manni-Bucau >> @rmannibucau >> http://www.tomitribe.com >> http://rmannibucau.wordpress.com >> https://github.com/rmannibucau >> >> >> 2015-01-06 10:27 GMT+01:00 Anatole Tresch <[email protected]>: >> > 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* >> > > > > -- > *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*
