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
_______________________________________________