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
_______________________________________________