Werner, We understood you are an old Java guy but can you try to propose something concrete and work on tamaya instead of listing all frameworks you worked with/on?
Anatole, Mark and I proposed the content of the api and we got only a few feedback so how to move forward in such a thread then? Please go back on proposals and build the content you think is right from there. If you dont want or dont have time please just leave this thread until we sort it out and help us on coming topics bit we need to start to shape an outcome now IMHO. If it helps I can certainly work with Mark on a github "demo". Wdyt? Le 20 juil. 2016 00:20, "Werner Keil" <[email protected]> a écrit : > The 0.2 API JAR of Tamaya including the SPI counts roughly 20 elements. > Compared to ~60 in JCache. The JAR size doesn't necessarily reflect the > size or complexity of a JSR. > JSR 330 consisting only of half a dozen annotations can't be taken as a > "reference" for every JSR, as you mentioned without CDI, Spring or some > other DI container it has no real value of its own. > > JSR 354 which targets 2 different environments and in theory the while > "convert" part could be a separate module at the very least in its current > 1.0 Final state comes close to 60 types including the SPI so a tiny bit > more than JCache, the JAR is also 20k bigger. > CDI API 1.2 consists of nearly 100 types! A somewhat comparable JAR size as > Money-API 1. > > Should CDI 2 be better modularized because of that, yes, do you think it'll > be just 3, 5 or 10 elements even in the SE "minimal" module, think for > yourself. > > So modularization before even thinking of the standards part is clearly a > good idea. CDI 1 or Java 5-8 were not created with that in mind, which is > why it's now so tedious to break them down into small pieces, but API > anorexia is neither clean nor useful either;-) > > Cheers, > Werner > > > > On Tue, Jul 19, 2016 at 11:57 PM, Mark Struberg <[email protected] > > > wrote: > > > Let’s not drift from one extreme to the other. > > > > One extreme: (userland api only) 3 classes > > Other extreme:(tamaya current api): ~25 classes > > > > The middle ground I did propose (userland api + spi) has 5 classes. > That’s > > merely 2 more than the minimal BUT it is usable, extensible and flexible. > > > > LieGrue, > > strub > > > > > > > Am 19.07.2016 um 23:14 schrieb Anatole Tresch <[email protected]>: > > > > > > But we provide a bit more than annotations only. Our API is still > > complete > > > and basically usable. And the same discussion goes into the extensions > > > part: without extensions there is not si much benefits, but getting > > > extensions standardized might be even more difficult... > > > > > > 2016-07-19 22:20 GMT+02:00 Mark Struberg <[email protected]>: > > > > > >> > > >>> Am 19.07.2016 um 17:45 schrieb Anatole Tresch <[email protected]>: > > >>> > > >>> Not providing any kind of mechanism, but > > >>> the API also makes us less vunerable to discussions about how > > >> configuration > > >>> should be organized, which ultimately is the main issue, why > > >> standardizing > > >>> it is so difficult. So from a political perspective it may be an > > >> advantage > > >>> NOT to define the mechanisms behind, but only provide the main > > mechanism > > >> to > > >>> access it, the API. > > >> > > >> I see the point, but I fear it falls a bit too short. > > >> Think about JSR-330 (atinject). It only provides the ‚consumer‘ API. > > >> Is it usable? No, it _always_ needs another spec to be usable. Be it > > CDI, > > >> Guice or Spring. > > >> It is *absolutely* impossible to provide a portable solution based on > > >> atinject alone. > > >> It is just the least common denominator of a few frameworks. > > >> > > >> Do we like to do that? > > >> If so, how does a user build it’s applications in a *portable* way? > > >> Without any SPI or very simple default ways to configure your app this > > is > > >> imo impossible. > > >> That’s the reason why I really would love to see the SPI as part of > > such a > > >> spec. > > >> > > >> LieGrue, > > >> strub > > >> > > >> > > > > > > > > > -- > > > *Anatole Tresch* > > > PPMC Member Apache Tamaya > > > JCP Star Spec Lead > > > *Switzerland, Europe Zurich, GMT+1* > > > *maketechsimple.wordpress.com <http://maketechsimple.wordpress.com/> * > > > *Twitter: @atsticks, @tamayaconf* > > > > >
