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*
