| Re: [cdi-dev] CDI Lite compatible extension lead |
|
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 Rahman Jakarta 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 -------- 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 |