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> on behalf of Emily Jiang
via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
*Date: *Friday, November 17, 2023 at 8:45 AM
*To: *jakartaee-platform developer discussions
<jakartaee-platform-dev@xxxxxxxxxxx>
*Cc: *Emily Jiang <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!OIHO0vrz7WYxLesx7AAw9ucX4uUTVGL2Y9BMXhL_HFv4XE94_Ga5U4nQ8QZt12qtSXEpHM6TlHkmDf_071ivyK14wUp9Iavz$>) 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!OIHO0vrz7WYxLesx7AAw9ucX4uUTVGL2Y9BMXhL_HFv4XE94_Ga5U4nQ8QZt12qtSXEpHM6TlHkmDf_071ivyK14wc7iVOnz$>). 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!OIHO0vrz7WYxLesx7AAw9ucX4uUTVGL2Y9BMXhL_HFv4XE94_Ga5U4nQ8QZt12qtSXEpHM6TlHkmDf_071ivyK14wd44orcL$>
_______________________________________________
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!OIHO0vrz7WYxLesx7AAw9ucX4uUTVGL2Y9BMXhL_HFv4XE94_Ga5U4nQ8QZt12qtSXEpHM6TlHkmDf_071ivyK14wVaEfCq_$>
_______________________________________________
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!OIHO0vrz7WYxLesx7AAw9ucX4uUTVGL2Y9BMXhL_HFv4XE94_Ga5U4nQ8QZt12qtSXEpHM6TlHkmDf_071ivyK14wVaEfCq_$>
--
Thanks
Emily
_______________________________________________
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!OIHO0vrz7WYxLesx7AAw9ucX4uUTVGL2Y9BMXhL_HFv4XE94_Ga5U4nQ8QZt12qtSXEpHM6TlHkmDf_071ivyK14wVaEfCq_$
