| Re: [microprofile-wg] [External] : Re: : Re: : [Discussion] Context Propagation 1.3 Specification Release Review |
Nathan,
I'm okay with some type of compromise. I don't hold a controlling vote and I also can't speak to what other members might think.
My goal is that we inform our users correctly and consistently so
that we aren't later, trying to recover from unmet expectations.
Some type of text that indicates the core of this thread, that is
'likely' to be seen by a prospective user/implementation vendor,
would probably suffice.
I would not be in favor of suggesting that users change the TCKs -- unless that is explicitly allowed for, in the TCK instructions and/or documentation. Once this option starts to be available it becomes hard to keep "oh, just this minor tweak" from happening. We should try to promote the position that the TCKs as fixed -- with only very explicit, documented exceptions allowed.
My preference would be that EE 8 users stick with 1.2 and EE 9 (and beyond) users use 1.3. I'm not sure if there is already maintenance that is in 1.3 that a 1.2 user would desire. That might complicate things.
Thank you for working with me on this question.
Cheers,
-- Ed
> If there is an explicit statement in the specification text that says this specification must be used with any particular version of Jakarta EE, it didn't change.
This is correct. The specification has no statement requiring a particular Jakarta EE version.
> If an implementer wants to upgrade their existing implementation from CP 1.2 to 1.3 -- and edit their POM.xml to point to CP 1.3 -- Would that new implementation pass the TCK?
It depends on how well the existing implementation is written, whether written in a modular fashion that implements only MicroProfile Context Propagation, versus written in a tightly coupled manner with unrelated stuff that might have other dependencies. If written in a modular fashion, then yes, just swap out the binaries underneath and run it against the TCK. The 1.3 TCK is provided in terms of jakarta package names, so if anyone wants to run it with javax package names, they would either need to transform it first or just use the identical 1.2 TCK which is already in javax packages.
I understand your argument for wanting a new major version, but this exact scenario was already brought forward and decided on for this release and the 1.3 version is consistent with the decision that was made. Could a compromise here be to revisit that discussion for subsequent MicroProfile releases?
From: "Ed Bratt" <ed.bratt@xxxxxxxxxx>
To: "Microprofile WG discussions" <microprofile-wg@xxxxxxxxxxx>, "Nathan Rauh" <nathan.rauh@xxxxxxxxxx>
Date: 11/17/2021 07:44 PM
Subject: Re: [External] : Re: [microprofile-wg] : [Discussion] Context Propagation 1.3 Specification Release Review
Sorry, I wasn't trying to take a position, one way or another. I'm asking what is required. It sounds like you are asserting that the CP spec. is required to run with elements of an EE Platform. That's perfectly reasonable. ZjQcmQRYFpfptBannerStart
This Message Is From an External SenderThis message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Sorry, I wasn't trying to take a position, one way or another. I'm asking what is required. It sounds like you are asserting that the CP spec. is required to run with elements of an EE Platform. That's perfectly reasonable.
In the CP 1.3 spec. document the code-examples are all modified from javax to jakarta. The other textual change is in "Other Changes" under Release Notes for 1.3, at the end which says (paraphrasing): the TCK and Code Examples are updated to use the Jakarta EE 9 namespace. If there is an explicit statement in the specification text that says this specification must be used with any particular version of Jakarta EE, it didn't change.
I think we agree, if the TCK is changed, that implies the Spec. is changed.
If an implementer wants to upgrade their existing implementation from CP 1.2 to 1.3 -- and edit their POM.xml to point to CP 1.3 -- Would that new implementation pass the TCK?
If the TCK can support either -- Jakarta EE 8 (and javax) or Jakarta EE 9 (and jakarta) -- then the answer to the previous question could be 'yes.' If the TCK doesn't provide compatibility verification for EE 8 then, I think the answer is 'no.'
Perhaps where I'm getting to is: if the 1.3 TCK can be used to verify compatibility for EITHER Jakarta EE 8 or Jakarta EE 9, the minor release increment is appropriate. If the TCK can ONLY verify compatibility for EE 9 -- to my way of thinking -- the upgrade is incompatible since we know that EE 8 (with javax namespace) is incompatible with Java 9 (jakarta n.s.).
I understand there are no substantive changes to CP. Honestly, it seems easier to me (well, it would have been two months ago) to just change the release designation to a major release -- rather than update the TCK to support both versions of Jakarta EE. We already have a TCK that supports EE 8 -- that's the CP 1.2 TCK. I've worked on other Specs. where we decided that, even though there we were proposing no incompatible changes, would be dependent on an updated Spec., that does contain incompatible changes -- and we propagated that incompatible notion forward declaring a major release.
Thanks,
-- Ed
On 11/17/2021 2:11 PM, Nathan Rauh wrote:
Ed,
MicroProfile Context Propagation has dependencies on Jakarta EE only in that it defines a mechanism for capturing, establishing, clearing and removing Jakarta EE context from threads (this includes java:comp namspace of application components, JTA transactions, as well as other types, such as CDI). It explicitly enumerates the interactions with these and other types of context within the Context Propagation API and describes the behaviors that you get, all without the Context Propagation API/SPI having any direct code dependencies on the corresponding Jakarta EE components. I have to disagree with your assertion that the lack of such dependencies means that the TCK contains tests that are beyond the scope of the specification. The fact that the specification defines interactions/behaviors with Jakarta EE components is alone sufficient to justify the TCK testing with this same set of Jakarta EE components that the spec defines interactions with. The TCK should be testing these things because, as you stated, the specification is ALL OF the written documents, binaries, ... and so forth. And that makes the interactions that are defined within those documents fair game for TCK testing.
From: "Ed Bratt" <ed.bratt@xxxxxxxxxx>
To: "Microprofile WG discussions" <microprofile-wg@xxxxxxxxxxx>
Date: 11/17/2021 01:24 PM
Subject: Re: [microprofile-wg] [External] : [Discussion] Context Propagation 1.3 Specification Release Review
Sent by: "microprofile-wg" <microprofile-wg-bounces@xxxxxxxxxxx>
Emily, Thank you for starting a discussion 'side' thread. I didn't see that happen before so I didn't realize that was our custom. I thought there had been other plan reviews for MicroProfile component specifications, but I see that I was mistaken ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender">This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Emily,
Thank you for starting a discussion 'side' thread. I didn't see that happen before so I didn't realize that was our custom.
I thought there had been other plan reviews for MicroProfile component specifications, but I see that I was mistaken in that impression. I would encourage us to adopt that in future releases but I'm willing to concede this is not an issue for MP 5 specifications and I apologize for raising it as an concern for CP 1.3.
If the CP Specification truly has no dependencies on the Jakarta EE components, I wonder if perhaps the TCK contains tests that are beyond the scope of this Specification. I'd ask the development team: Is there an Assertion that is traceable to the Specification (text or Java Docs), tested in the TCK, that requires a specific Jakarta EE version. If there is no such assertion, perhaps the Jakarta EE version elements in the TCK are incorrect and should be removed. If the Specification documentation does require a specific version of Jakarta EE -- then, this test should remain. This would be consistent with David's suggestion, but changing the TCK, at least in my book -- is a change to the Specification, to wit ...
I would encourage us to adopt the position that the Specification is ALL OF the written document (the Specification document and/or Java Docs), the Binary Artifacts (API JARs, etc), AND the TCK. These each provide important aspects of the Specification and any change to a component element, should be considered a change in the Specification.
In summary, if it is determined the CP 1.3 specification /does/ require Jakarta EE 9, I'd encourage us to communicate that incompatibility to our users and fellow implementer groups by designating this a major release, not a minor release. If EE 9 is not a CP requirement, the minor version change is totally appropriate and (probably) the TCK should omit those tests.
I apologize for raising this so far into this project program.
Thank you,
-- Ed
On 11/17/2021 4:15 AM, Emily Jiang via microprofile-wg wrote:
I have a suggestion on the voting thread. If there are comments related to the voting, I suggest we start a new thread so that the voting thread can stay focused with the voting.
I started this discussion thread to follow the discussion on Context Propagation 1.3 release.
As for MP Context Propagation 1.3, the spec and api are identical to MP Context Propagation 1.2. I would say the api and spec produced in MP Context Propagation 1.3 will work with either Jakarta EE 8 or Jakarta EE 9. In this context, the spec 1.3 is backward compatible with 1.2. In other words, if you drop MP Context Propagation 1.3 api jar in your Jakarta EE 8 runtime, it works without any problem.
If you want to run the certification, you can use the tck jar produced by MP Context Propagation 1.2, and use 1.3 for Jakarta EE 9. Therefore, you may not need to transform any jakarta or javax.
Does this address your question, Ed?
p.s For minor vs. major releases for Jakarta EE 9.1 alignment, we discussed this topic on one of our live hangouts (6th July). I asked the minor release vs. major release question and suggested we do a minor release for the specs with only tck dependencies on Jakarta EE. There were no objections.
Thanks
Emily
On Tue, Nov 16, 2021 at 10:53 PM Emily Jiang <emijiang6@xxxxxxxxxxxxxx> wrote:
As for plan review, after MicroProfile Working Group was established in 2020, we started with a release view. We did not put the plan review in the process. We can revisit this in 2022. As a matter of fact, we will start using the Plan Creation Review for new specs (see here). We should follow the steps laid out by EFSP 1.3.
As for the minor vs major changes for Context Propagation, as mentioned in the release plan, the api jar has no dependencies on javax, this release is purely for any runtime that wishes to run its tcks using jakarta namespace. I think minor changes make sense.
Therefore, I think the top option as suggested by David makes sense.
- Keep the minor version change and:
- be ok to accept CCRs from Jakarta EE 8 based impls that have used bytecode tools to modify the CP 1.3 TCK itself back to the 'javax' namespace
Thanks
Emily
On Tue, Nov 16, 2021 at 9:15 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
On Nov 16, 2021, at 12:38 PM, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:
1) Was there an approved plan review for Context Propagation 1.3? (I'm missing my record of that and apologize if I just lost this.)
Good callout. I think we've missed Plan Reviews in general:
- https://github.com/microprofile/microprofile-wg/labels/Plan%20Review
We definitely need to do those from now on.
2) All the other specifications are making major releases due to the incompatible changes required by Jakarta 9.1. While the Context Propagation API may not have a direct dependency on Jakarta EE APIs, it seems the TCKs may. Is it confirmed this is a minor-release compatible update? Should a user running on Jakarta EE 8, expect to be able to upgrade their implementation to Context Propagation 1.3 successfully without also upgrading their Jakarta EE dependency? Should a vendor anticipate supporting both EE 8 and 9 with this release?
More good questions. I see that we did update the namespaces in the TCK.
I'd be hesitant to establish a rule where major changes in the TCK need to result in a major version change. That said, we're not talking strictly about changes in the TCK (say moving from Junit to TestNG) that do not have an impact on the server itself. The change in the TCK does require a change in the server and that creates some ambiguity in my mind.
Here are some potential resolutions that seem to make sense to me:
- Keep the minor version change and:
- be ok to accept CCRs from Jakarta EE 8 based impls that have used bytecode tools to modify the CP 1.3 TCK itself back to the 'javax' namespace OR
- issue our own javax version of the CP 1.3 TCK, which Jakarta EE 8 based impls can chose as an alternate to the jakarta namespace CP 1.3 TCK
- Update the major version
Any other options people see?
-David_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
--
Thanks
Emily
--
Thanks
Emily
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg
_______________________________________________
microprofile-wg mailing list
microprofile-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/microprofile-wg