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 --------
Date: 9/18/20 2:33 AM (GMT-05:00)
Subject: Re: [cdi-dev] CDI Lite compatible
extension lead
Hi Laird,
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
_______________________________________________