[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [microprofile-wg] [External] : Re: : [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.
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://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/microprofile-wg__;!!ACWV5N9M2RV99hQ!cY21YWTIAniBuj0851oRyWrtLzTuedf9s_2KXcqFPUu1hemqdHsUmugt3ZEj5f4$