| Re: [jakarta.ee-spec.committee] Requiring visibility on optional features |
I like the approach of having the TCK results highlight the optional vs required aspects of the Specification. But, that will be easier said than done. I know the Platform TCK is very convoluted with the parameters required to run or not run the optional tests. And, the actual results do not highlight this aspect in the least. So, as stated below... We would have a ways to go to get this right, but I like the desire.
FYI just for more background, the Platform TCK keyword.properties
currently maps the keywords to certain Platform TCK test folders.
Note that the `javaee_optional` + `javaee_web_profile_optional` are
(too) big test buckets.
At a high level, with the EE 10 Platform TCK, I think we will
have more flexible capabilities via JUnit5 LauncherDiscoveryRequest
+ DiscoveryFilter
as well as TestNG test
groups, however the actual tests for each desired optional
capability also need to be isolated from the other optional
capabilities in order to allow for more specific test
categories. We will be
discussing these options on the Platform TCK mailing list in
more detail.
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From: David Blevins <dblevins@xxxxxxxxxxxxx>
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date: 07/14/2021 16:17
Subject: [EXTERNAL] Re: [jakarta.ee-spec.committee] Requiring visibility on optional features
Sent by: "jakarta.ee-spec.committee" <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Jul 14, 2021, at 10:37 AM, Scott Stark <sstark@xxxxxxxxxx> wrote: What I was saying during that call is that the spec and associated TCK should make the optional features and associated tests manifest such that simply providing the
On Jul 14, 2021, at 10:37 AM, Scott Stark <sstark@xxxxxxxxxx> wrote:
What I was saying during that call is that the spec and associated TCK should make the optional features and associated tests manifest such that simply providing the TCK results in the CCR makes it manifest what optional features are supported by the implementation. I'm saying the burden is on the spec project to simplify the reporting.
Great, I hadn't specified if such reporting would be manual or automated, just that it should occur. A summary of the TCK results are part of the CCR, so that would fit the goal.
The TCK often doesn't agree with the spec on what is optional, so we'd likely have to live with that imperfection in the short-term and reconcile it over time.
One also has to question why a feature in a specification is optional independent of who is implementing it. Lack of flexibility with respect to the TCK and many other legacy aspects cannot continue to weigh down this project.
I think we all agree on that.
-David
On Wed, Jul 14, 2021 at 12:30 PM David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
On Jul 14, 2021, at 8:30 AM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
Flagging up this idea for today's discussion as I think it was overlooked and something we'd all agree is desirable.
On Jun 23, 2021, at 2:44 PM, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
A potential proposal is that each spec must keep an inventory of optional features and each CCR must accurately report which they do and do not implement.
In brief:
1. We'd have a section in each spec with a simple list of optional features
2. A CCR would have that same list and indicate what they do and do not support
This relates to our discussion in these two ways:
- Ed's inventory was mostly complete and I'm sure took considerable time, proving it's very hard for even us to know what is or is not optional
- We've said things like, "If everyone implements it it maybe shouldn't be optional", but we have no way of knowing what people do or do not implement
To me it seems we'd need both of these things to make more progress in the future beyond the immediate action of dealing with CMP/BMP and Embedded EJB Container.
As an analogy we want to cut down our expenses (optional features), but we don't have a clear idea of what are expenses are (what is actually optional) and if we need them (if none, some, or all of us implement them). I don't see a way to jump to the end and "cut all expenses", when we don't even know what they are or if we need any of them.
If we would like to make more aggressive progress we need this awareness. If we don't want to make aggressive progress, we don't need this awareness, we can keep dealing with the worst cases one by one.
-David
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To 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 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 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 unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee