[jakarta.ee-spec] Additional Requirements defined outside a Component Sp

[David Blevins <dblevins@xxxxxxxxxxxxx>]

Capturing some of the conversation from today's spec committee call per Paul's request.

Agree in spirit that if we're releasing new TCKs -- be they service, minor or major -- ensuring they can be passed is essential.  Since we are doing that work to ensure they pass, I don't see an advantage to skipping the CCR.  That's another topic, however.

On the statement that because we added Java 11 as a requirement for the platform this now becomes a requirement for all included components, I don't agree.  My perspective on it is any specification, platform or component, does have the ability to add or alter requirements that relate to an included or referenced component specification, however, it is the spec adding those requirements that has the burden to test and prove those additional requirements.

Some examples:

 - Jakarta Enterprise Beans can say "when you use CDI with EJB, the EJB interceptors are called before the CDI interceptors."

 - Jakarta Enterprise Beans can say "when your JAX-RS endpoint is an EJB, the endpoint class does not need to be listed in a JAX-RS Application class"

 - Jakarta EE Platform can say "a Servlet must be able to access the `java:module` and `java:app` namespace"

 - Jakarta EE Platform can say "all EE implementations and their components must support Java 11"

In the above scenarios it is the EJB and Platform specifications adding the requirements and therefore their TCKs that must prove the requirements our met with their own compatible implementations. (ignore that there is no EJB TCK)  In the same scenarios it would not be the burden of the CDI, REST or Servlet specifications, TCKs or compatible implementations.

In the future we may have independently released profiles and this situation will get more cumbersome if we allow several independently released profiles to each set their own, possibly conflicting, set of requirements to the same component specification and it results in that component specification team having to produce a single TCK that meets the externally defined requirements.  The only way it works is if each profile has the burden to create the tests for their additional requirements, put them into the profile's own TCK and get their own compatible implementations to pass them.

I use profile so it is easier for people to understand because it's a less subtle analogy, but as mentioned any spec can say "we use/require these other specifications and here's how they work in our context."  IMO, the spec making the statement owns the TCK and implementation work.


Now, that said I thought of a new point of discussion assuming we buy into the above.  It does put into question wether it is legitimate to say "I passed the Foo Profile TCK, it includes component spec Bar 2.0, therefore I can file a certification request for Bar 2.0"  That opens some interesting questions like what if Foo Profile only includes part of Bar 2.0.  No need to discuss that now, just, fyi.


-- 
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com