[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cu-dev] : RE: Checking in -- progress towards finishing Concurrency Utilities 3.0?
|
Dmitry/Ed,
The latest obstacle to come up is the final release process itself. What
I described doing in previous emails with the Release Candidate API and
TCK jars on maven and using an implementation that is compatible with
those to make our final release is not the Jakarta EE process. It is the
MicroProfile process, which I'm familiar with because I've done several
times. I assumed (wrongly) that it would also be valid for Jakarta EE
because both are Eclipse projects. However, from what I have been hearing
from discussions on the platform list, this isn't so. I'm actually
thoroughly confused about it and need help from the rest of you. If we
put the wrong thing into the Open Liberty beta, there is no second chance
to get it right -- at least not until beyond the EE 10 cutoff.
First I should clarify what I have previously misstated.
Compatible implementation - I have been using this term incorrectly.
According to
https://www.eclipse.org/projects/handbook/#specifications-implementations
“Compatible Implementations may only claim compatibility with a final
specification. ... No claims regarding compatibility may be made for an
implementation milestone build or unratified specification version."
Given this, an implementation that runs against a Release Candidate API
and TCK and documents its fully passing results is not a compatible
implementation at all. It's only a candidate to become a compatible
implementation, which can only happen if it runs against and passes the
final release API and TCK, which cannot be the same as the Release
Candidate due to differences in the version within the artifacts.
To get a final release, we need to complete the checklist in
specifications repo (linked in the original email from Ed) for a release
review,
https://github.com/jakartaee/specifications/blob/master/.github/PULL_REQUEST_TEMPLATE/pull_request_template.md
which states,
"For a Release Review, a summary that a Compatible Implementation is
complete, passes the TCK, and that the TCK includes sufficient coverage of
the specification."
This is where I get lost because this looks like a cycle:
Compatible Implementation requires final spec release.
Final spec release requires Compatible Implementation.
The only way I can reconcile this is if both of these things happen at the
same time rather than one before the other, which might be how other
specifications are getting around this. If I understand correctly,
discussion on the platform list suggests that others are relying on a
staging repo to keep their final release API/TCK hidden while they build
and release compatible implementations which certify on copies which they
externalize of that, and the API/TCK from the staging repo later gets
published to maven after the specification becomes final. This is not how
Open Liberty does things (as is probably evident from certain responses on
the platform discussion) and it is uncertain whether we will have any
success in getting the Open Liberty community to deviate from its
standards for the sake of getting this specification released. If this is
the only way, we can at least try.
Please let me know if I am missing anything here. If I now have the right
understanding of the Jakarta EE/Eclipse process, it means we need to be
creating a Final release API/TCK/specification next week rather than a
Release Candidate and putting it into staging.
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: "Ed Bratt" <ed.bratt@xxxxxxxxxx>, "Nathan Rauh"
<nathan.rauh@xxxxxxxxxx>, "Steve Millidge (Payara)"
<steve.millidge@xxxxxxxxxxx>
Cc: "cu developer discussions" <cu-dev@xxxxxxxxxxx>, "DMITRY.KORNILOV"
<dmitry.kornilov@xxxxxxxxxx>
Date: 01/14/2022 03:54 AM
Subject: RE: [External] : RE: [cu-dev] Checking in -- progress
towards finishing Concurrency Utilities 3.0?
I’m not aware that any work has been done on concurrency-ri to bring it up
to speed with the new capabilities in Concurrency 3.0 so I don’t think
that is an option for this release. From: Ed Bratt <ed.bratt@xxxxxxxxxx>
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
I’m not aware that any work has been done on concurrency-ri to bring it up
to speed with the new capabilities in Concurrency 3.0 so I don’t think
that is an option for this release.
From: Ed Bratt <ed.bratt@xxxxxxxxxx>
Sent: 13 January 2022 23:43
To: Nathan Rauh <nathan.rauh@xxxxxxxxxx>; Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx>
Cc: cu developer discussions <cu-dev@xxxxxxxxxxx>; DMITRY.KORNILOV
<dmitry.kornilov@xxxxxxxxxx>
Subject: Re: [External] : RE: [cu-dev] Checking in -- progress towards
finishing Concurrency Utilities 3.0?
Nathan,
There is some CI infrastructure in place for the CU project (
https://ci.eclipse.org/cu/). It might be useful for completing this
specification version.
The CU project consists of some bits of compatible implementation (stuff
in concurrency-ri) which I believe constitute a CI. As I understand it,
concurrency utilities is of the class of components that requires some
additional infrastructure to host and validate the TCK. (for example,
Enterprise Security has a Compatible Implementation that only work when
integrated with something more substantial, like an EE Platform -- the
same, I believe is true of CU). That said, I see that the previous
compatibility requests were made for Eclipse GlassFish -- I think you can
decide if you want to repeat that, or just request a CCR for the
(unfortunately named concurrency-ri project).
Based on previous releases it might be possible to either perform a local
build of Eclipse GlassFish that includes the CU compatible implementation
jar and API -- or, work with the GlassFish team to integrate your proposed
final CI and API JAR into GlassFish -- using that build, run the current
TCK and you have what you need (the archived CI would be the the
concurrency utilities implementation, not the GlassFish version that it
was integrated into).
It looks like Dmitry Kornilov ran these tests last time they were run. He
might recall these details more clearly.
Thanks,
-- Ed
PS, after this API is finalized, we should consider splitting it into an
implementation and Spec. project. The Spec. project could then be moved
into jakartaee GHO.
On 1/13/2022 6:45 AM, Nathan Rauh wrote:
I just noticed that Ed was somehow left off of the cc list when I replied
yesterday. Sorry about that. I have just added him back on.
As far as I'm aware, every 3.0 enhancement for which a pull was submitted
has been fully added to the specification and TCK, with nothing in a
partial state except for the pending work to add TCK coverage for the new
resource definition annotations in EJB container and possibly JSPs, which
are being worked on. We should create a 3.1 milestone in github to
collect up a list of enhancements/issues that didn't make 3.0 (such as the
one you mentioned) that could go into Jakarta EE 11. If everyone is happy
with this outcome, the main help that will be needed is the timely
creation and publish to maven of the 3.0 RC1 image next week after those
final TCK update(s) go in. Starting/continuing on your implementation is
probably the best way to help at this point so that there is a contingency
plan if this doesn't make the Open Liberty beta in time. The odds became
a bit more favorable because I just noticed that Kyle has successfully
finished addressing all of the review comments on the TCK port issue, and
so I've merged it in. Thist just leaves the pending TCK scenario(s) for
resource definition annotations to get in next week.
From: "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To: "Nathan Rauh" <nathan.rauh@xxxxxxxxxx>, "cu developer
discussions" <cu-dev@xxxxxxxxxxx>
Cc: "DMITRY.KORNILOV" <dmitry.kornilov@xxxxxxxxxx>
Date: 01/13/2022 06:38 AM
Subject: [EXTERNAL] RE: [cu-dev] Checking in -- progress towards
finishing Concurrency Utilities 3.0?
Hi Nathan, Dmitry
I should remember how to push artifacts to maven central assuming the old
Jenkins jobs haven’t got “bit rot”. I was hoping to get an api change for
this issue MaxConcurrency annotation · Issue #136 ·
eclipse-ee4j/concurrency-api · GitHubbut tbh I’m not going to get the
time.
I haven’t been following this as closely as I should due to many and
varied things. Are we OK with spec doc or do I need to pull some of my
team in to drive this forward more?
Our team is starting to look at the implementation of this on Payara 6
alpha 3 but not sure we can meet the Feb deadline with a Compatible
Implementation. We likely have more flexibility in pushing out alphas than
perhaps OpenLiberty. Is Feb 28th really a drop dead deadline for have a
CI ready if the API is finalised?
Steve
From:Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Sent: 12 January 2022 19:26
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Cc: DMITRY.KORNILOV <dmitry.kornilov@xxxxxxxxxx>; Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx>
Subject: Re: [cu-dev] Checking in -- progress towards finishing
Concurrency Utilities 3.0?
I can help provide some of the estimated timeline assuming that we will
need to use Open Liberty as the compatible implementation upon which to
certify. Toward the end of last year I sent an email out querying if
there were any other implementations that could be used as the compatible
implementation that would meet the Feb 28 deadline, and thus far haven't
heard back from any others.
Here's how the schedule would line up:
The pull to port over the old TCK bucket to the Concurrency project and
merge it with the new TCK tests that have already been written for
Concurrency 3.0 is currently in review state. It appears that all of the
review comments thus far have been very minor and so I expect it to be
merged relatively soon, probably within the next few days.
After this, one of the participants is working on a remaining new TCK test
to include the new resource definition annotations on an EJB. That will
need to be submitted, reviewed and merged, hopefully early next week.
After that, an official RC1 build will need to be performed, and the spec
API jar and TCK jar published to maven. I have no idea how to do either
of these things, but hopefully Steve knows or either of you who are
helping to mentor will know and can help with it.
If that can all be done by January 19, then we should be able to get it
into the next beta release of Open Liberty.
Every day beyond that point over the next week will have an increasingly
lesser chance of making the February beta. I don't expect Open Liberty
will hold up or change its release schedule for just this spec.
When the February beta comes out around the beginning of February, then we
would be able to collect official results of the TCK running with the 3.0
RC1 release on the Open Liberty beta as the compatible implementation. It
will take several days further to get those results published to a
publically accessible location, but it would be well before the Feb 28
deadline.
The main risk here is getting the 3.0 RC1 image created and published to
Maven in time.
If another implementation with a more flexible schedule or more lenient
approach to certification comes along, that would certainly help add some
time. But absent that, we do at least have a path to meeting Feb 28,
albeit a narrow one.
From: "Ed Bratt" <ed.bratt@xxxxxxxxxx>
To: "cu developer discussions" <cu-dev@xxxxxxxxxxx>, "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
Cc: "DMITRY.KORNILOV" <dmitry.kornilov@xxxxxxxxxx>
Date: 01/12/2022 11:55 AM
Subject: [EXTERNAL] [cu-dev] Checking in -- progress towards
finishing Concurrency Utilities 3.0?
Sent by: "cu-dev" <cu-dev-bounces@xxxxxxxxxxx>
Hi,
Dmitry Kornilov and I have been assigned by the Specification Committee to
mentor you through the process of finalizing the Release PR for the
upcoming release review of Jakarta Concurrency 3.0 for inclusion in EE10.
As a part of wave 1 in the Jakarta EE 10 Release Plan, the release review
PR could be made at any time. You may create the PR even if you don't have
all the information required. Just mark it as DRAFT and work on it
together with your mentor (me).
Are you on track with finishing up this specification version and creating
a PR for this specification in the specificationsrepository? Are you able
to estimate when the team anticipates starting this final step?
Is there anything blocking/delaying the release?
Is there anything Dmitry or I can help you or the project team with?
Thank you,
-- Ed_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cu-dev
