Re: [jakarta.ee-spec.committee] Requiring visibility on optional feature

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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.

---------------------------------------------------
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