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$
