Allow Jakarta EE 9.1 level APIs, but require TCKs pass and CCRs are clear

[dblevins]

This PR attempts to achieve the following:

• Maintain a strong Jakarta EE 10 focus
• Make it clear there is still a breaking change as Jakarta EE 9.1 individual APIs are not required
• Maintains Jakarta TCKs must be passed, even when Jakarta EE 9.1 is the base

The intention is to maintain as much forward progress as possible (enabling 10, requiring tcks be passed, breaking change that 9.1 isn't required) while still allowing EE 9.1 impls to support MP 6.0.

I did not touch the pom.xml and intend to leave it as-is as we did for Metrics. This ensures things favor the majority of implementations. TomEE users are already not using the Eclipse jakartaee-api jar as it is implementation-specific and includes Eclipse Mojarra, Eclipse Mail, and Eclipse Activation which directly conflict with our own implementations Apache MyFaces, Geronimo Mail and Geronimo Activation.

[NottyCode]

The phrase:

Additionally, 6.0 adds requirements for all required Jakarta TCKs to be passed.

seems redundant since that requirement was already there.

[dblevins]

Do you mean it was already there in other sections that mention 6.0 or was already there in 5.0?

[NottyCode]

I mean there was a long discussion a few years back about whether or not a MicroProfile implementation required the CDI/JAX-RS and JSON-* specifications to pass and my understanding of the conclusion of that discussion was that they were. Making it clearer in the text that this is required is obviously a good thing, but stating that you are adding a requirement that was already there reverses the outcome of the discussion we had in the past about CDI/JAX-RS and JSON-* TCKs needed to be passing.

[dblevins]

@NottyCode it was the reverse. Prior to this PR from John in October the spec said, "Passing the Jakarta specifications TCKs is optional." I was attempting to be consistent with that PR and state that if you are on Jakarta EE 9.1, passing the related Jakarta TCKs is still required.

[Emily-Jiang]

In the past, it was argued that CDI TCKs contained EJB, which was not supported by MicroProfile. The whole point of Jakarta EE 10 Core Profile was to fix the problem so that Jakarta EE 10 Core Profile can be consumed by MicroProfile and strengthen up the compliance, which was why MP adopts Jakarta EE 10 Core Profile.

[dblevins]

We are ok passing all related Jakarta EE 9.1 TCK tests.

[NottyCode]

I'm surprised to read this given the email thread on this subject concluded with the following:

Thank you for the good discussion. I think in the interest of moving things forward we can wrap this up as there being no real support for including MicroProfile 6.0 implementations based on Jakarta EE 9.1. Not due to technical limitations, but due to preference, which is ok.
https://groups.google.com/g/microprofile/c/ZngsfSv3RrQ

[dblevins]

See my note on the list. Emily reached out me and there was another discussion on Tuesday where some willingness to revisit was expressed and I was requested to create a PR for people to evaluate.

[rdebusscher]

But I think there are technical problems. A user can build an application with MP 6.0 API as the sole dependency and can use, for example the classes BeanContainer, BuildCompatibleExtension, EntityPart, etc..

The application builds fine but fails deployment as those classes are not available in a Jakarta EE 9.1 runtime.

So the compatibility no longer means it is able to run all applications build on top of the MP 6.0 API and thus certification s meaningless for vendors and users.

[NottyCode]

@dblevins Can you provide me with a link to the discussion on Tuesday? I don't see it on the list.

[dblevins]

@NottyCode it was the on the technical call. I don't know where those are being posted these days. @jclingan is that up anywhere?

[rdebusscher]

Allowing this will undermine the credibility of the MicroProfile certification and compatibility program as there is no guarantee anymore that a compatible product will run the application that is compiled against the MicroProfile umbrella API artifact.

[edburns]

Microsoft opposes this proposal. As the only hyperscale cloud actively
participating in MicroProfile, and also participating in Jakarta EE,
we are investing heavily in creating partner co-developed Jakarta EE
solutions for Azure. We have sufficient business data to support that
our customers want compatibility guarantees for Jakarta EE from their
MicroProfile implementations as well.

[dblevins]

@edburns this does still guarantee compliance at Jakarta EE 9.1 or higher and Java 11 or higher.

[edbratt]

MicroProfile 6 was (I thought) originally intended to require Jakarta EE Core Profile -- which is only defined in Jakarta EE 10 and higher. If a vendor is still using earlier versions of Jakarta EE, they should use the version of MicroProfile that matches the Jakarta EE version they require.
I did not anticipate that the MicroProfile 6 specification would support either Jakarta EE 9 (or 9.1) or 10.
I had thought that by asserting the Core Profile requirement, this was creating a requirement dependency from of the Jakarta EE Specification. If we are going to revert this to, "a set of Jakarta EE specifications that MicroProfile defines," as the MicroProfile EE base, then I fear we have not succeeded in delivering a suitable Jakarta EE "Core" for MIcroProfile.
My opinion is: MicroProfile should simply assert that implementations meet the compatibility requirements defined in Jakarta EE Core Profile. Further, (to me, this was implied) since Core Profile doesn't exist in earlier versions, it is not possible to satisfy this with implementations that pass TCKs from previous versions of Jakarta EE specifications.
I had, perhaps improperly read the statements about implementation dependencies on earlier Jakarta versions as recommendations that vendors look to earlier versions of MicroProfile. If that is unclear, we certainly could update the language to correct that. I would rather not extend MicroProfile 6 to be either Jakarta EE 9 (or 9.1) or Jakarta EE 10.

[Emily-Jiang]

MicroProfile 6 was (I thought) originally intended to require Jakarta EE Core Profile -- which is only defined in Jakarta EE 10 and higher. If a vendor is still using earlier versions of Jakarta EE, they should use the version of MicroProfile that matches the Jakarta EE version they require. I did not anticipate that the MicroProfile 6 specification would support either Jakarta EE 9 (or 9.1) or 10. I had thought that by asserting the Core Profile requirement, this was creating a requirement dependency from of the Jakarta EE Specification. If we are going to revert this to, "a set of Jakarta EE specifications that MicroProfile defines," as the MicroProfile EE base, then I fear we have not succeeded in delivering a suitable Jakarta EE "Core" for MIcroProfile. My opinion is: MicroProfile should simply assert that implementations meet the compatibility requirements defined in Jakarta EE Core Profile. Further, (to me, this was implied) since Core Profile doesn't exist in earlier versions, it is not possible to satisfy this with implementations that pass TCKs from previous versions of Jakarta EE specifications. I had, perhaps improperly read the statements about implementation dependencies on earlier Jakarta versions as recommendations that vendors look to earlier versions of MicroProfile. If that is unclear, we certainly could update the language to correct that. I would rather not extend MicroProfile 6 to be either Jakarta EE 9 (or 9.1) or Jakarta EE 10.

+1. The current staged spec was clear on this. See here.

[dblevins]

My concern with pushback on this now is we did spend months getting the group to address this explicitly and conducted a vote. The vote text was:

"A MicroProfile specification should not change versions just for a new Jakarta EE version unless the MicroProfile specification must change to support the new Jakarta EE version. It is possible for a MicroProfile specification version to work on multiple versions of Jakarta EE."

The basic goal here is to "compile low, run high" which means that we want to target the API to the lowest Jakarta EE version supported by the API and then all users and implementors of the API can then run on higher Jakarta EE versions if desired.

That vote passed with 9 +s and no -1 votes on August 11th in the thread [VOTE] Version changes for new Jakarta EE versions. That vote was open for 3 months, discussed on several community calls and the vote was explicitly mentioned in the minutes of May 24th and June 7th minutes. Jan even gave two presentations. None of the feedback given on this PR was given in that several-month discussion or vote.

Additionally, there were several discussions on ensuring the TCKs could pass on both Jakarta EE 9.1 and Jakarta EE 10. Much of that was in the community and tech calls. Some written traces of that are the PR Make sure TCKs are CDI-version agnostic and the September 13th community call minutes [Emily] MP Config TCK needs to have one test updated to enable both Jakarta EE 9.1 and 10 to pass. We were asking for this as we intended to pass the MP 6.0 TCKs on our Jakarta EE 9.1 implementation.

Now, I do see the Plan Review did explicitly mention the Core Profile as a requirement and we did vote +1 on that Plan Review. I will admit fault there. My father had a heart attack at that time and I cast my vote quickly before leaving to the airport knowing I'd be unavailable after, not anticipating a disconnect given the months of discussion about ensuring we don't raise the Jakarta EE level unless there was technical need and ensuring all MP 6.0 TCKs could pass on Jakarta EE 9.1.

We did our very best to ensure this was openly discussed and we could be part of the MicroProfile 6.0 implementations.

What we're asking does not prevent anyone from shipping MicroProfile 6.0 on Jakarta EE 10.

The pushback does, however, only affect our ability to claim MicroProfile 6.0 compatibility. As people pile on, explicitly to block us from getting certified, knowing their own ability to ship as they see fit would not be hindered, it becomes a difficult pill to swallow.

I know people don't like to be wrong and it's easy to get locked into "fight till you're right" mode. I am sincerely requesting you do not see it that way. Here's some insight on us and why your support would be so greatly appreciated.

• TomEE has struggled to catch up with all TCKs across both working groups
• We spent the year focusing exclusively on MicroProfile, changing our implementations so we could get caught up
• This would be the first time since MP 2.0 that we'd be current with the MicroProfile umbrella spec near the time the spec was released
• We have been waiting to get caught up so we can finally spend more time adding new features to the MP specs and providing implementations for the release votes. This was our plan for next year.

I beg you to see the good that approving this PR can create for us and MP.

[Emily-Jiang]

@dblevins Thanks for your comments! I understand your feeling. I have a few comments for consideration.

1. As for the vote you mentioned, I am not sure how it will be able to apply to the platform release, as it directly pulls in the exact version of Jakarta EE APIs. For MicroProfile umbrella release:
   MP 1.0 - exposes Java EE 7
   MP 2.x - exposes Java EE 8
   MP 4.x - exposes Jakarta EE 8
   MP 5.0 - exposes Jakarta EE 9.1
   MP 6.0 - exposes Jakarta EE 10 Core Profile (since the community wanted to pull in Jakarta EE 10 Core Profile and get rid of the scafolding CDIs -excluding EL, EJB etc)
   I am not sure when people votes, they consider the umbrella relase as a spec or not. I do think all of MP component specs are operating on the basis of "compile low, run high".

2. Your PR will get a runtime that not support Jakarta EE 10 claims the compliance. However, based on the mailing list coversation and this PR's conversation, not supporting Jakarta EE 10 core profile still allows an application using CDI 4 APIs but they will fail at runtime. I think getting an runtime onto the compatible page might not the ultimate goal. It is better to have consistent behaviour during compile time and runtime.

3. I have been thinking how to resolve this. I think we can update the structure to produce two separate pom.xml - one with Jakarta EE 9.1 and the other with Jakarta EE 10, something like multi-module support.
   I have raised this issue to get this addressed in the upcoming relases.