By the way, I am not a big fan of profiles. Profile is an overloaded world already. Jakarta EE itself has the concept of Web Profile, Full Profile, etc. Now, in CDI, we are trying to define many profiles. This would cause a lot of confusion.
Me too :)
I am with Mark on the points of - CDI Lite needs to be the subset of CDI if we call it CDI Lite; We should not change the defined behaviour (I am against the idea of ignoring the content of beans.xml and scan jars regardless of the bean-discovery-mode setting).
Exactly, CDI lite is naturally means that it is the subset of the full CDI API.
If you want to introduce new APIs and totally different processing model than CDI ( processing annotations at build time, removing extension points, etc.), then I think we need to call it a different name, spec etc. It is not a CDI.
In the meantime, there are different types of DI providers (Spring, Micronaut, Quarkus, etc…). Each of them has different set of APIs.
Why don’t we integrate these ideas into the current CDI specification? What is the blocker?
By the way, I am not a big fan of profiles. Profile is an overloaded world already. Jakarta EE itself has the concept of Web Profile, Full Profile, etc. Now, in CDI, we are trying to define many profiles. This would cause a lot of confusion.
I am with Mark on the points of - CDI Lite needs to be the subset of CDI if we call it CDI Lite; We should not change the defined behaviour (I am against the idea of ignoring the content of beans.xml and scan jars regardless of the bean-discovery-mode setting).
Thanks
Emily
On Tue, Jan 26, 2021 at 4:18 PM Ladislav Thon <lthon@xxxxxxxxxx> wrote:
Hi,
I think that's very nice, and quite close to what we've just
discussed on the call. (Meeting minutes coming :-) )
I'd like to get back to the "defining feature", if I may. I have
probably misunderstood you completely. At this point, there's no
new _feature_ proposed, no new API, no new configuration, etc.
(except the new extension API, which is just inevitable fact of
life and I guess we would all be happier if we didn't have to do
them :-) ). It's mostly about restructuring or redefining of
what's already there, in a way that doesn't break existing CDI
users yet allows CDI to be used in more environments (notably, in
an environment that "pre-wires" beans during application build).
Hope that I said it better than the last time.
LT
On 26. 01. 21 16:22, Manfred Riem
wrote:
Hi,
As it is clear that we are NOT gravitating
towards a solution here I would like to pivot and propose an
alternative that could be hopefully acceptable to all parties
involved.
Drop the
notion of CDI Lite
Introduce
the notion of CDI profiles
Define 3
profiles for the CDI specification
CDI
CDI – CP
(Core Profile)
CDI – BTF
(Build Time Profile)
Make 3c an
optional profile as far as the specification is concerned
(EE runtimes should not have to be required to support 3c)
Where 3b is a proper subset of 3a and 3c is
a subgroup of 3b (or in other words 3c uses 3b and it is
allowed to add its own incompatible “sugar”).
Thoughts?
Thanks!
Kind regards,
Manfred Riem
From: cdi-dev
<cdi-dev-bounces@xxxxxxxxxxx>On Behalf Of
Ladislav Thon Sent: Tuesday, January 26, 2021 7:59 AM To:cdi-dev@xxxxxxxxxxx Subject: Re: [cdi-dev] About parsing beans.xml
files in Lite
Hi,
On 26. 01. 21 15:27, Manfred Riem wrote:
I am sorry you think me asking for the
one defining feature is inconvenient and make you feel like
going around and around, but from my perspective it is a
very important question to answer.
no, that's not inconvenient, I understand
the desire to have a "defining feature" -- I'm just pointing
out that we already went through a very similar discussion
(here on this mailing list).
What is the one defining feature for CDI
itself? I would argue when most folks think about CDI they
think Dependency Injection.
So my question stands! What would most
folks think this to be named variant would stand for?
Everything I have heard so far does not
tell me that as I have only heard implementation concerns.
I don't think it's an implementation concern. If the
specification can't be implemented under certain constraints,
then either such implementation doesn't make any sense, or the
specification needs to change. I personally believe it's the
latter.
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
