| So we don’t have a web profile or platform spec TCK job setup that is capable of pulling in a selection of staged api release artifacts to validate them. This means that a spec project that does not have a standalone TCK needs to be incorporated into some platform TCK run that builds against the staging repos of all the candidate releases we want to provide evidence of a compatible implementation. For Red Hat that means setting up a variation of our currently Wildfly nightly run that pulls in the staged release artifacts.
This has several problems: 1. We can’t really document how to run this in a persistent manner as soon as the staging repos are gone the instructions are invalid. 2. It is a lot more work than simply setting the versions of the api artifacts to test against.
Take the Jakarta Stable APIs spec project and associated Jakarta Management, Jakarta XML Registries, Jakarta XML RPC, Jakarta Deployment API projects. Especially for this no-functionality update Jakarta EE 8 release, it seems overkill to have to run a platform TCK to validate their release.
Either a common platform TCK job that can be run to validate staged releases is needed, or non-platform/non-standalone projects need to be able to have candidate releases that are validated by platform releases with iterations on the candidate releases until the platform TCK validates them.
Right now I don’t see what we have defined as practical for every specification project.
Bill,We're all in agreement
on not rev'ing any of the current Java EE 8 implementations. Not
Glassfish, not Open Liberty, not Wildfly... But, we may need to do
some special one-off processing just to satisfy all of us that the deliverables
for Jakarta EE 8 are solid. We can talk more about this on Friday's
call.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
Bill
Shannon <bill.shannon@xxxxxxxxxx>To:
Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Kevin Sutter <sutter@xxxxxxxxxx>Date:
07/10/2019
04:01 PMSubject:
[EXTERNAL]
Re: [jakarta.ee-spec.committee] Clarification on API TCK tests to be executed
First, July 15 is just the "preview"
date. July 22 is when it's really supposed to be done so the ballot
can start.
I think it's up to the Steering Committee to adjust the plan after JESP
1.2 is approved. I would suggest that we continue to drive as many
specs as possible to the July 15/22 date. Those that don't make it
can take advantage of the 14 day review period. If we allow everything
to slip, we'll increase the risk substantially.
I'm not in favor of weakening the requirements, which are already significantly
less than we would expect for a "normal" release. Allowing
some extra time where needed should be sufficient. And again, we
are not doing a new release of GlassFish; GlassFish 5.1 will be
the Compatible Implementation, tested with the Jakarta EE 8 platform TCK.
Kevin Sutter wrote on 7/10/19 12:04 PM:Okay... I
think this will just be another hurdle for these individual projects to
jump over with very little time left in the schedule... I know some
of the Spec Projects are making great strides in this area, but there are
others that haven't done anything yet. I know that David is attempting
to help with the Spec generation exercise, but that's just one piece of
the puzzle. Running the individual TCKs against the updated APIs
is going to take time. Even though everyone says it's "easy",
it's not for newbies. And, our documentation isn't all published
yet...
So, maybe our next order of business is to develop an alternate plan...
If we don't make the July 15 date, what's our next plan? Even
if we get an updated JESP that allows us to shorten the review cycle to
15 days (vs 30), are we going to stick with the original plan of action?
Or, are we going to adjust something?
For example... As a backup plan... Once we think all of the
APIs have been properly updated, can we spin off a Compatible Implementation
build and TCK execution using these updated APIs? This is not what
we would ship, but it would verify that all of the API updates didn't break
anything. Maybe it's a special branch of the CI. This would
validate all of the APIs, while not requiring a new release of Glassfish,
or Open Liberty, or Wildfly...
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From: Bill
Shannon <bill.shannon@xxxxxxxxxx>
To: Jakarta
specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>,
Kevin Sutter <sutter@xxxxxxxxxx>
Date: 07/10/2019
01:45 PM
Subject: [EXTERNAL]
Re: [jakarta.ee-spec.committee] Clarification on API TCK tests to be executed
As discussed in today's meeting, no, I don't agree with this.
We need a full TCK run of a compatible implementation in order to approve
a spec. I understand that the timing is tight and some of them might
not be ready by Monday, or even the following Monday when the real review
is scheduled to start. We do have some extra time in the schedule
once JESP 1.2 is approved so that should allow more than enough time for
projects to complete a full TCK run.
If anyone is having trouble getting the TCKs to work, please ask for help
sooner rather than later.
Kevin Sutter wrote on 7/10/19 7:06 AM:
Hi,
All of the individual Jakarta EE Spec Projects need to create their skeletal
spec documents and provide their TCK results for the updated APIs. I've
had the question raised about how much of the TCK needs to be executed
against these updated APIs. My response has been only the TCKs that
actually verify the APIs -- not the full implementation. In most
cases, this would equate to running the signature tests (although some
components have more elaborate "APIs" that need further testing).
I have also been advocating that if this simplified TCK can be run
without requiring an application server -- all the better!
Are we all on the same page with this direction? Thanks!
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
e-mail: sutter@xxxxxxxxxx
Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
_______________________________________________ jakarta.ee-spec.committee mailing list jakarta.ee-spec.committee@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
|
