On 17.11.2023 18:22, Ondro Mihályi via jakartaee-platform-dev wrote:
> [..] CDI shouldn't
> depend on any other dependency besides Java SE, it should be one of the
> core Jakarta EE specifications.
I do see that at this point cdi-api has 5 dependencies, including
jakarta.el-api for instance. Is jakarta.el part of Java SE or is that
part of the CDI itself?
I generally agree that CDI should be a "core" spec, but the claim that it shouldn't depend on anything but Java SE is overly restrictive in my opinion.
There are a few specifications that are even more fundamental than CDI: Common Annotations, Dependency Injection (part of the CDI project), Interceptors. (To be honest, the Interceptors spec, having to serve both CDI and EJB, is a strange beast and doesn't really serve CDI very well. If I could, I would fold it into CDI.)
In addition to these, CDI depends on the CDI Language Model (which could be moved away from CDI easily -- some specifications expressed interest in this API, so we made it a separate artifact to ensure we don't accidentally make it depend on anything CDI) and _expression_ Language. The EL dependency only exists because of 2 methods in `BeanManager` which are AFAIK only useful for integrating into a container that includes EL. We're working on removing this dependency from the core CDI API; in CDI 4.1, we're deprecating these methods and providing a replacement (which is outside of the core CDI API), and we plan to remove them in CDI 5.0.
LT
thanks,
--lukas
If we move all EE-related stuff from CDI
> to related specs, those specs would depend on CDI at compile time, not
> the other way around.
>
> Ondro
>
> On Fri, Nov 17, 2023 at 6:18 PM Nathan Rauh via jakartaee-platform-dev
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:
>
> It’s certainly true that a specification that covers CDI integration
> will need TCK tests of the CDI integration. There are a variety of
> strategies already available for ensuring TCK coverage. Platform
> TCKs are one good place for covering integration. Component TCKs
> can do so as well, provided they have modes for running in Jakarta
> EE profiles vs standalone. The latter would require a compile
> dependency to build the TCK, but no run time dependency on CDI when
> running in the standalone mode. I don’t see why that should be a
> problem because TCKs already have compile dependencies on all sorts
> of artifacts. But if Jakarta Persistence for some reason doesn’t
> want that approach, they still have the option of covering
> integration requirements in platform TCKs. TCKs are not a right
> justification for requiring the creation of new specifications.____
>
> __ __
>
> *From: *Emily Jiang <emijiang6@xxxxxxxxxxxxxx
> <mailto:emijiang6@xxxxxxxxxxxxxx>>
> *Date: *Friday, November 17, 2023 at 10:43 AM
> *To: *Nathan Rauh <nathan.rauh@xxxxxxxxxx
> <mailto:nathan.rauh@xxxxxxxxxx>>
> *Cc: *jakartaee-platform developer discussions
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
> *Subject: *[EXTERNAL] Re: [jakartaee-platform-dev] [cdi-dev]
> Discussion: The new structure of EE integration sections____
>
> Nathan, Not sure whether you were on this week's platform call. If
> spec has the CDI dependencies, the TCKs will have dependencies on
> CDI. I think Lukas does not want the spec to rely on CDI. The
> runtime that supports both CDI and Persistence ____
>
> ZjQcmQRYFpfptBannerStart____
>
> *This Message Is From an External Sender ____*
>
> This message came from outside your organization. ____
>
> * Report Suspicious *
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJDRIpn0my8bFK8l4j3WvBcGnwzWuF7-dcqTCv1BmLWu0O6MEeEeppxsa_gFAOXDxY7AT0aN65LK4hHlnfE-37ODE3EhdsNg7zYJrfMnzh3GmJxkTqmGA2mI$> ____
>
> ZjQcmQRYFpfptBannerEnd____
>
> Nathan,____
>
> Not sure whether you were on this week's platform call. If spec has
> the CDI dependencies, the TCKs will have dependencies on CDI. I
> think Lukas does not want the spec to rely on CDI. The runtime that
> supports both CDI and Persistence can use CDI extension to provide
> the additional Beans such as EnitityManager for injection.____
>
> Thanks____
>
> Emily____
>
> __ __
>
> On Fri, Nov 17, 2023 at 3:13 PM Nathan Rauh <nathan.rauh@xxxxxxxxxx
> <mailto:nathan.rauh@xxxxxxxxxx>> wrote:____
>
> Jakarta Persistence doesn’t need to define a dependency on CDI
> just to write about CDI in the Persistence specification
> document. Unless there is some deeper issue about needing to
> define Jakarta Persistence API classes that compile against CDI
> API classes, no dependency should be required. If the deeper
> issue does exist, then it is one of the rare exceptions. If I
> followed the links that you provided in your original email, the
> changes are all in the specification document text and some
> xml-related files – nothing that requires compilation against
> CDI.____
>
> ____
>
> My main point here is that I don’t want to see the more drastic
> solution for the corner case problem to be enforced for the sake
> of consistency across all integration points where it isn’t
> necessary in the majority of cases. Possibly I didn’t
> understand your statement in the original email for the solution
> “to be consistent across the platform project.” I understood
> that to mean the solution will be applied to all integration
> points across the Jakarta platform for consistency.____
>
> ____
>
> ____
>
> *From: *jakartaee-platform-dev
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>> on behalf
> of Emily Jiang via jakartaee-platform-dev
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
> *Date: *Friday, November 17, 2023 at 8:45 AM
> *To: *jakartaee-platform developer discussions
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
> *Cc: *Emily Jiang <emijiang6@xxxxxxxxxxxxxx
> <mailto:emijiang6@xxxxxxxxxxxxxx>>
> *Subject: *[EXTERNAL] Re: [jakartaee-platform-dev] [cdi-dev]
> Discussion: The new structure of EE integration sections____
>
> Ondro, Nathan, What Ondro said does not address the dependency
> issue, which was the reason to have the 2 proposals. As for CDI,
> it puts dependencies on other specs and other specs have
> dependencies on CDI, which creates circular dependencies. ____
>
> ZjQcmQRYFpfptBannerStart____
>
> *This Message Is From an External Sender *____
>
> This message came from outside your organization. ____
>
> * Report Suspicious *
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJDRIpn0mYUQd4sEg92kdKZCi1tdScISeQyrMsCrXuBegx8LdPoHVhZZaN65YtDXQ40KN1fru4DHMSaGfYdhkWk1yJ4Q6tGScNxk3RSZyRCareyJd3Z0rDpC$> ____
>
> ZjQcmQRYFpfptBannerEnd____
>
> Ondro, Nathan,____
>
> ____
>
> What Ondro said does not address the dependency issue, which was
> the reason to have the 2 proposals. As for CDI, it puts
> dependencies on other specs and other specs have dependencies on
> CDI, which creates circular dependencies. For Persistence, as
> discussed on this week's platform call, the Persistence spec
> team does not want the integration to be present in that repo as
> it does not want to declare the dependency on CDI because Spring
> or others will use it potentially.____
>
> ____
>
> Thanks____
>
> Emily____
>
> ____
>
> On Fri, Nov 17, 2023 at 2:35 PM Nathan Rauh via
> jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:____
>
> I agree with Ondro’s response that introducing new
> specifications for integration requirements is overdoing it,
> and favor what he suggests in his second paragraph below
> (can this be Proposal 3?), that the specification define the
> integration requirement to apply when the other Jakarta
> specification is present. I have used that approach many
> times in Jakarta specifications and it works very well: "In
> environments/profiles where Jakarta specification X is
> available, … must happen." It helps to have the outermost
> specification--most distant from core profile or most
> distant from wave 1--define the requirement. Generally, that
> is easily done.____
>
> ____
>
> It should be an extremely rare case where this doesn’t solve
> the problem, and only in those exceptional cases should it
> be necessary that proposal 1 or 2 be used. I don’t want to
> see proposal 1 or 2 applied across the board to all
> integration points between specifications. That would cause
> unnecessary churn in specifications and burden already
> thinly stretched specification teams with additional work
> that has little, if any, value.____
>
> ____
>
> ____
>
> *From: *jakartaee-platform-dev
> <jakartaee-platform-dev-bounces@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx>> on
> behalf of Ondro Mihályi via jakartaee-platform-dev
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
> *Date: *Friday, November 17, 2023 at 4:24 AM
> *To: *jakartaee-platform developer discussions
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>>
> *Cc: *Ondro Mihályi <mihalyi@xxxxxxxxxxx
> <mailto:mihalyi@xxxxxxxxxxx>>, cdi developer discussions
> <cdi-dev@xxxxxxxxxxx <mailto:cdi-dev@xxxxxxxxxxx>>,
> jpa-dev@xxxxxxxxxxx
> <mailto:jpa-dev@xxxxxxxxxxx><jpa-dev@xxxxxxxxxxx
> <mailto:jpa-dev@xxxxxxxxxxx>>
> *Subject: *[EXTERNAL] Re: [jakartaee-platform-dev] [cdi-dev]
> Discussion: The new structure of EE integration sections____
>
> From the 2 proposals, I favor the option 1 (already
> existing platform/profile specs) But I think a cleaner
> solution is that individual specs like persistence, or
> servlet define this behavior in case CDI container is
> present. Faces and Transactions ____
>
> ZjQcmQRYFpfptBannerStart____
>
> *This Message Is From an External Sender *____
>
> This message came from outside your organization. ____
>
> * Report Suspicious *
> <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/PjiDSg!12-vrJA1yxHVsKtWOKHJwMOJoeIYgm32bsAX8ECrog84gVNZuNteH8TCuJoCOBwkAGjXqptM2yFpJUUnKORLxwPreByrzVQIhq14EgnX3EmB-YVk7xMVfyom9RdD$> ____
>
> ZjQcmQRYFpfptBannerEnd____
>
> From the 2 proposals, I favor the option 1 (already
> existing platform/profile specs)____
>
> ____
>
> But I think a cleaner solution is that individual specs like
> persistence, or servlet define this behavior in case CDI
> container is present. Faces and Transactions already do so,
> they define custom scopes or @Transactional interceptor.
> Other specs should do so too. If those specs don’t do accept
> that, the I would define it in the platform/profile specs as
> a last resort.____
>
> ____
>
> But introducing a new spec looks like an overkill for me.____
>
> ____
>
> Ondro____
>
> ____
>
> On Thu, 16 Nov 2023 at 17:00, Matej Novotny via
> jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:____
>
> The Proposal 2 is what has been voiced during CDI calls
> by multiple people (me included) but has been repeatedly
> decided against; although I fail to recall the reasons
> now.____
>
> I am definitely for option 2 as that's way simpler to
> keep track of as opposed to creating multitude of other
> separate projects.____
>
> ____
>
> As for the ownership I don't see that as a con, or
> rather, I don't think there is much difference between
> putting the spec/tcks into platform bits and into
> separate "EE integration" project.____
>
> After all, it's integration of spec X and spec Y which
> already implies there should two be interested parties
> participating on that spec part and relevant TCKs.____
>
> So maybe it would be even better to have these parts
> stored on a "neutral ground" so to speak (platform
> spec/tck) so that both parties can cooperate there
> without arguing whose responsibility that is based on
> where that code currently resides.____
>
> ____
>
> Just my 0.02$____
>
> Matej____
>
> ____
>
> On Thu, Nov 16, 2023 at 4:19 PM Emily Jiang via cdi-dev
> <cdi-dev@xxxxxxxxxxx <mailto:cdi-dev@xxxxxxxxxxx>>
> wrote:____
>
> Further to this week's discussion regarding where to
> put EE integration chapters for Jakarta
> Specifications, we need to discuss offline to
> evaluate the approaches. At the moment, CDI EE was
> proposed to be a new spec (see here
> <https://urldefense.com/v3/__https://github.com/jakartaee/specifications/pull/665__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQwhEkutj$>) while Jakarta Persistence with CDI integration was proposed to be added to the platform specification (see here <https://urldefense.com/v3/__https://github.com/jakartaee/platform/pull/746__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ50OGs_L$>). It is better to be consistent across the platform project.____
>
> ____
>
> Context: some Jakarta EE specifications have
> integration parts with other Jakarta EE
> specifications, such as CDI or potentially Jakarta
> Persistence.____
>
> ____
>
> Issue: These dependencies might introduce some
> circular dependencies among the specs. In order to
> avoid the circular dependencies, the integration
> parts need to be somewhere else.____
>
> ____
>
> Proposals:____
>
> *Proposal 1: Create a new specification to hold all
> of the integration part, such as CDI EE, Persistence
> EE*____
>
> *Pros:*____
>
> The ownership is clear to start with but it might
> not be once the relevant specs start adding tcks.____
>
> ____
>
> *Cons:*____
>
> The number of specs might be increased dramatically.____
>
> For some certification with web/core profile or
> platform, separate parts are to be spelled to
> differentiate web/core profile or platform
> implementers.____
>
> ____
>
> ____
>
> *Proposal 2: put the integration part to Core/Web
> Profile or Platform specifications under separate
> modules.*____
>
> *Pros:*____
>
> The number of the specs will not change.____
>
> It is clear that certification for core/web profile
> and platform are clear which tcks are to be
> executed.____
>
> This can be released when releasing the platform or
> web profile or core profile. However, these TCKs can
> be released individually.____
>
> ____
>
> *Cons:*____
>
> The ownership is less clear. It might not be an
> issue if the involved spec teams work together on
> this or the tests clearly document the owners.____
>
> ____
>
> ____
>
> Please add other proposals and cons/pros I missed.____
>
> -- ____
>
> Thanks
> Emily____
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev@xxxxxxxxxxx <mailto:cdi-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cdi-dev
> <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/cdi-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ-nZVuCr$>____
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$>____
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$>____
>
>
>
> -- ____
>
> Thanks
> Emily____
>
>
>
> -- ____
>
> Thanks
> Emily____
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
> <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$>
>
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!KEH9aMs4t1YxOZHvqfmtpDW2zx5Hq_MVJIFMe3vLBWJaIC8ZQvLXyPFa2s2hQ3IRULaJB8jtzadQ3MwThMYmq_JFQ94mOsO9$
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
