| Re: [cdi-dev] CDI Lite compatible extension lead |
Hello,
I'm a newbie on this list, but I'm just an ordinary man, nothing special, nothing grand, so please allow me to skip the introduction and get to the point :-)
I have authored the PR [1] and the blog post about it [2], so I feel kinda responsible for what happened. Communication is hard, especially for introverted people like me, so let me try to set things straight. I'll probably just repeat what Matej already said, but ... well, I need to start somewhere.
The desire for a "lite" variant of CDI was expressed by multiple people, on various places, starting a long time ago. During various discussions (at least those that I've seen), one point occured repeatably: whatever CDI Lite has or not, it needs to have an extension mechanism. In other words, Portable Extensions are immensely popular and people don't want to lose them. Totally understandable. At the same time, it seems rather obvious to me that Portable Extensions can't be used, because they are inherently runtime and heavily based on Java Reflection API, while CDI Lite should be implementable [= possible to implement, not constrained to] at build time. (This has also been stated many times by many people way before I got involved.)
Some people at Red Hat started thinking about how a new extension API, amenable to build time processing, could look like, and I got involved too. That's the "we" (and I should probably submit a PR to the blog post to clarify this). We use the name "Build Compatible Extension" for now, to distinguish from Portable Extensions.
Now, if I understand correctly, you're all caught by surprise that what we've published last week seems very complete, and looks like we're just throwing it over the wall. That itself catches me by surprise, because it really is not. If you look into the API, there's many TODOs big and small, and it is more of a "vertical slice". That is, only one part of it (the annotation transformation API, aka @Enhancement) has been developed more thoroughly, the other parts went through just a short debate and were only included to show that we realize there's more to it than just annotation transformation.
What I mean is -- we published a sketch. We also said that everything is up for debate. I don't know of a better way to start a discussion than to publish a concrete proposal. I'm a simple man, I find it easier to build abstract ideas from concrete things, and I don't believe in API design without implementation (that's why I built a POC, too).
When I hear that this wasn't discussed, I'm getting confused.
Noone started any kind of a discussion (that I know of -- I got
involved fairly recently). This is what we're trying to do --
bring up some concrete ideas so that the discussion can start.
Anyone and everyone should feel free to publish alternative
proposals, including ideas how to make Portable Extensions
build-time-friendly, etc. etc.
When I hear that this wasn't discussesd, I'm also starting to feel guilty. It feels like I violated some universal code that I wasn't aware of. For that, I apologize.
LT
P.S.: when it comes to discussion medium, I really think GitHub
issues would be more appropriate, and they integrate with e-mail
rather seamlessly, but I don't mind using a mailing list either.
[1] https://github.com/eclipse-ee4j/cdi/pull/451
[2] http://www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension/
To be honest, I had the same feeling as Laird and Reza and I commented on the PR with confusion. I think maybe some of you involved in the project head down and made progress, but the others were not aware of this and did not feel they were engaged.
For future development, can we settle down on the following?1. Use jakarta-cdi to raise issues and discuss issues - list the end user story, problems, etc. Blog is for something else. I think wherever we want to make changes, we should raise an issue and discuss first.
I saw Matej raised the issue after the PR. I think it should be the other way around. In this case, we can collaborate on the design and we agree with the rough design. Then comes PR, so people can review on the details and less time-wasting. At the moment, a lot of comments on the PR is about what the design should look like.
2. As for cdi-spec repo, I don't see why we still need this. Can we merge this into jakarta-cdi repo so that we have one central place to collaborate with?
3. If needed, e.g. a lot of confusion and disagreement on the issue, we should call out an one-off hangout to discuss. Even in JCP time, we have regular communications so that people are aware of what we are working on.
Thoughts?
ThanksEmily
On Sun, Sep 20, 2020 at 9:01 PM Scott Stark <starksm64@xxxxxxxxx> wrote:
I don't see how this could be taken as close to final in any way when the opening post is saying this is the start of a discussion regarding a proposed set of apis. There are github issues and a previous blog introducing the topic months ago. The only issue I see is lack of integrating the blog and github issues with this dev list. The dev list should at least have a link anytime an issue or blog is created.
Again, this is just the start of a discussion to see if there even is common ground on which to build a native approach.
_______________________________________________On Sun, Sep 20, 2020 at 2:45 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
_______________________________________________To be honest, I also was taken a little by surprise as to how "final" and "sudden" the proposal felt. In the future, maybe a better approach would be to inform folks here that a concrete and detailed proposal is being worked on?
Now, moving back to the more technical and forward looking aspects. What is the thought as to whether this proposal should replace the older portable extensions API altogether? How much capability would be lost? The reason I mention this is because there is some intrinsic value to be able to write CDI extensions using one uniform API that works everywhere.
Also, I hope all the vendors can agree on an approach that is right for native compilation. In fact the ideal case for me would be if as a result of this work, CDI adoption by frameworks could be broadened overall beyond just one additional runtime (e.g. Quarkus). Has some assessments of these factors been made as part of this proposal or do we need to do that here, as part of this discussion?
Reza RahmanJakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
Hi Laird,-------- Original message --------From: Matej Novotny <manovotn@xxxxxxxxxx>Date: 9/18/20 2:33 AM (GMT-05:00)To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>Subject: Re: [cdi-dev] CDI Lite compatible extension lead
you didn't miss any communication.
There were discussions about CDI Lite on CDI repo, in MP circles and there was also the blog by Antoine some time ago[1] which I think was reposted to this list as well (would have to dig that up).
From those discussions, extensions were a pain point because Lite was supposed to be build time friendly and current extensions are anything but.
The proposal you seeing now is by far not anything we want to push into specification. It is a suggestion but instead of talking abstract designs, we wanted to try and come with something concrete.
It only tries to address Lite extensions - it doesn't solve the issue what Lite is and isn't. You can think of it as "if there was Lite spec, what would the extension API look like?".
To set the record straight, the website with blogpost (http://www.cdi-spec.org) is under previous CDI org on GH[2], not sure about who can post there.
It was used mainly because we needed a public place to put a rather big article with pieces of code samples - unfit for GH issue and even worse for emails if you ask me.
In order to make it properly public within jakarta cdi community, we then created a linking issue, PR and sent an email. All of this was published within a short time frame (with the PR coming earlier due to sync issues).
As for "we" references in the article - it definitely isn't speaking for whole committee! That would be daring, silly and rude; we don't mean to speak for anyone else ;-)
The references you are worried about (which I am not sure what they are) are likely referring to the group of people who tried to draft this API.
Now, circling back onto goals and motivation...
Like I stated above, this proposal isn't defining whole CDI Lite. It focuses on just the Lite extension APIs and seeing what those should look like in a version of CDI that is build-time friendly.
The motivation for Lite as such was mentioned throughout various previous discussions and posts and varies based on who is discussing that, but I dare generalize (so I am sure someone won't agree) that the idea was usage in microservices, cloud and build-time environment.
With the amount of questions you had, there is a chance I missed some, so please do ask again if you feel anything is unclear :)
Regards
Matej
_____________________________________________________________________________
[1] http://www.cdi-spec.org/news/2020/03/09/CDI_for_the_future/
[2] https://github.com/cdi-spec/cdi-spec.org
----- Original Message -----
> From: "Laird Nelson" <ljnelson@xxxxxxxxx>
> To: "cdi developer discussions" <cdi-dev@xxxxxxxxxxx>
> Sent: Friday, September 18, 2020 1:38:35 AM
> Subject: Re: [cdi-dev] CDI Lite compatible extension lead
>
> On Thu, Sep 17, 2020 at 4:18 PM Scott Stark < starksm64@xxxxxxxxx > wrote:
>
>
>
> This is a precursor to getting into a spec, so the work has been to extract
> an api from a build time implementation into something to begin discussions
> regarding how it might be standardized across implementation. From the blog
> by Antoine:
> http://www.cdi-spec.org/news/2020/09/15/CDI_Lite_extension/
>
> (By Ladoslav, I guess; just want to give credit where credit is due. Another
> question I had is: what's the relationship of that website to this list? Who
> can post there?)
>
> Is the "we" in that blog article this spec committee (and I missed it)? Or is
> it Red Hat, or some larger Jakarta EE group, or…? I just want to make sure
> I'm caught up and not missing messages/activity somewhere else.
>
> May I assume that the goals and use cases that motivated this overall effort
> are in that blog post? Or are they also laid out somewhere else? Should we
> spell them out explicitly on this list for long-term posterity? Or In Github
> Issues We Trust?
>
> Thanks for bearing with my questions.
>
> Best,
> Laird
>
> _______________________________________________
> 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
--
Thanks
Emily
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev