-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate artefacts for CDI lite and CDI full #640
Comments
This was discussed repeatedly in CDI calls and from the top of my head I recall these two major reasons why there is only one JAR present:
Now, I am by no means saying that the current state is ideal, just listing what I recall were the reasons for this choice. |
@manovotn is right on the money. I don't see how we could possibly "fix" this without breaking the world. |
But as described in my initial comment, CDI is now a bit of a mess. Which apparently can't be solved/untangled according to the replies. Nice. |
I just recalled there's an alternative option that I think we also discussed: ship 2 overlapping API JARs. I believe we rejected this because it would very easily lead to non-deterministic classpath situations. It's something we could reconsider, perhaps. |
I would keep an eye on this and see how many folks run into issues Rudy pointed out. It’s certainly a possible problem. It’s also possible in practice it’s OK the way it is. |
If users/developers report this kind of issues or just abandon Jakarta EE (most people are not very communicative about issues and just go find better alternatives) |
For the record: there was even a PR with tons of experts speaking out in favour of a split. It just got ignored and slammed. #582 |
That's curious, up until today, I didn't take tons to mean three :) Last but not least, like I stated earlier in this thread, the solution isn't perfect but that's what we arrived at and agreed on. |
|
I'd just like to point out that #582 does not split CDI Lite from CDI Full. It only splits the Build Compatible Extensions API, which achieves nothing with respect to the stated goals of CDI Lite, namely that CDI Lite is a strict subset of CDI Full. |
Again: CDI-Lite is not a subset of CDI-Full. CDI-Lite technically is all of the CDI-full API minus core CDI features, but plus build-time functionality.
This is imo much more where we are right now, isn't? |
Indeed and I did not say that.
That is correct and I never indicated that it would be otherwise either. I simply tried to explain that a different decision was agreed upon and the PR in question hanged open even after release.
OK, I guess. Let's agree to disagree. Again. |
CDI Lite is what the specification says it is. The manifestation of CDI Lite and Full APIs in a single JAR is an unfortunate effect of us actually caring about compatibility to the greatest extent practically possible. I'll reiterate the options we have considered, to my best recollection:
As this issue points out, we chose option 3. Maybe there are other options we should have considered but didn't -- I'd still like to hear about them. |
When you start with the requirement, we need a CDI lite that relies less reflection and doesn't break anything, the current solution is the only correct one. But introduces an incompatibility between future CDI 'extensions' since if an extension is not restricted to CDI lite functionality, it might break on Core Profile Products (and documentation and warnings are key here but not ideal) But more importantly, what about the user and if this technical requirement is something that benefits them and is easy and clear for the user? I have the impression that CDI lite is made just to allow some certification requirements but actually results in a not optimal user experience (my first reaction was to write 'bad user experience') for those who wants to use CDI lite - Core Profile - Quarkus (and potentially other products) The solution does not allow any compile time dependencies for your project that will result in a compiled binary that is guaranteed to run. And yes, user will see it very quickly that it fails, maybe even when Quarkus compilation already refuses to create your program. But if there is no good technical solution for a requirement, maybe it was better to drop CDI lite altogether and not push something that potentially puts Jakarta in a negative perspective. (Jakarta is useless since you can successfully This as feedback, I don't expect any solution in a future version. |
There are literally millions of ways how to create a program that compiles but doesn't run. As far as I'm concerned, this doesn't qualify as an argument against trying to shed some baggage and adapt to the ever-changing technology landscape. That said, I think there's at least one good idea to distill from this: we could/should require CDI implementations that implement CDI Lite but do not implement CDI Full to detect (as much as they practically can) usages of CDI features they do not implement and treat (some of) them as deployment problems. Failing early is always better than failing late. (In build-time implementations like ArC or ODI, "deployment time" is build time, so this would eliminate "compiles but doesn't run".) |
@Emily-Jiang @edburns This is issue is about what we discussed in the platform meeting, regarding CDI Lite not having its own jar split out. |
See also jakartaee/jakartaee-api#139 |
As CDI lite is new, could it not have used a new package? That would not have broken anything, would it? |
@arjantijms not really. CDI Lite is a subset of Full and as such uses many/most CDI functionalities but not all of them. |
Since there is only 1 artifact, containing both CDI lite and CDI full, it is not possible safely compile a program against CDI lite only, or build a CDI lite implementaton.
Developer viewpoint
Having the CDI full classes available in the API artifact means that a library/application compiled against this code might fail when running on a CDI lite implementation. Since the CDI full classes are available in the API, a developer can make use of it but the CDI lite implementation is not required to support them/have them available at runtime.
This is a bad user experience since a successfully compiled program using the API fails at runtime.
Implementation viewpoint
When developing an implementation, there is no API that can be added that contains only those classes that must be supported by the implementation.
The text was updated successfully, but these errors were encountered: