User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
On 26. 01. 21 23:13, Emily Jiang wrote:
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 don't think it's a new thing. CDI already has SE and EE "modes"
or "profiles".
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).
I guess we could just ignore beans.xml completely and mandate CDI
implementations to provide (in their native way) some means of
configuring which artifacts should be scanned.
LT
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.