I highly doubt letting anything fail is a good idea nor that it would be acceptable when it comes to passing a TCK.
Mark only brushed the surface because there is absolutely no problem splitting the main subpackages under https://github.com/eclipse-ee4j/cdi/tree/master/api/src/main/java/jakarta/enterprise into separate modules or even the SE part although that only has 2 elements Right now. We have not separated the JavaMoney API because that is much smaller compared to CDI or most other Jakarta EE libraries, but we (mostly Otavio and myself) cut the RI into separate modules: https://github.com/JavaMoney/jsr354-ri
moneta-core is one module while moneta-convert and its sub-packages are further separated so developers and users may chose from IMF, ECB or neither built-in conversion Providers, e.g. if they have their own or use additional ones like Google or Yahoo instead.
Werner
Gesendet von Mail für Windows 10
Good question, and I don't have an answer. Wanna help?
Thinking out loud:
One option is to not split anything, just let Lite implementations fail (or ignore) if non-Lite API is used.
Another option is to release 2 overlapping API artifacts and insist that they shouldn't be used at the same time, but that is way too fragile in my opinion.
Yet another option is to move classes around, but that would cause a huge pain, so I'd rather not do that either.
Any other ideas?
LT
On 12. 11. 20 9:50, Mark Struberg wrote:
How would splitting out the API work?
Since Java9 splitting up the same package into different jars is not a good idea (actually never was, but technically the JVM did not complain unless one of the jars was sealed).
strub
Hi,
Jason already said that, but I'll reiterate so that this doesn't fall through the cracks.
On 11. 11. 20 21:52, Mark Struberg wrote:
CDI core and CDI lite are different things. After reading the CDI-light proposal it appears to me, that it shares just the name 'CDI', but not much more.
It feels a bit like a different spec with main focus on running well on Graal and not needing any reflection or dynamic handling.
E.g. the wish to get rid of Contextual NormalScope proxies will kill CDI. This is literally the C in CDI !
Isn't it good that noone actually proposes to do that?! See for examplehttps://docs.google.com/document/d/1jS7EbHnyBBvZZxa56LmthKeoixm2FEHmqHwITGRLljQ/edit where I list what I think could/should be in the CDI Lite API.
What I propose to "remove" is, on the API level:
- decorators
- specialization
- conversations
- session scope
- non-contextual injection
- Portable Extensions
There's obviously more to it than the API, but it should give you an idea.
A lot of the dynamism of CDI can be achieved by generating code at build time. I haven't seen anyone wanting to "cripple" the essence of CDI -- it's all about being able to implement it under a different set of architectural constraints.
LT
I've added some comments.
And to clarify upfront: I'm not against such a spec. But it imo would not be CDI anymore. With removing all the dynamics we are back to Apache Avalon.
Werner: imo the jigsaw modularity only works well for the JDK itself. Never have seen it used in production due to various reasons.
Unfortunately this was done in a rather clumsy way particularly the " independent " SE Elements that make no sense in an EE context and vice versa.
While this was not in scope or targeted by around a third of all Jakarta EE 9 specs (and because of these issues I don’t recall CDI even bothered declaring a module in the MANIFEST yet) "Jigsaw" modularity that was archieved for the JDK itself will come as soon as Jakarta EE 9.1, so CDI2 was not the answer to a "CDI Lite" yet, it should be a "CDI Core" or whatever module in a future CDI Version that has other EE specific modules on top of it.
But this already got addressed in CDI-2.0 with the split into SE and EE parts of the spec.
A container not intended for JavaEE is free to not implement those Beans.
Or like we do it in Apache OpenWebBeans - keep it modular with a core which is just 700kB in size and all the integration is added on top of it.
or in retrospect shouldn't be in CDI
in the first place. Things like:
- decorators
- specialization
- session scope
- conversation scope
- passivation
- non-contextual injection
I always felt that just JSR 330/AtInject was way too small, while JSR 299/CDI might have been a tad too big. My personal pet peeve is the fact that CDI includes build-in beans for several Servlet types, such as HttpServletRequest. We tried hard before to get that out of CDI and into Servlet. Likewise, the build-in bean for Principal should likely belong in Jakarta Security, etc.
Though the conversation scope is technically not bound to Faces, maybe we should consider moving it to Faces anyway?
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
