| Re: [jakarta.ee-spec] Additional Requirements defined outside a Component Specification |
The level of effort with verifying that TCKs can be passed should be commensurate with the changes in the release. We already have spec project teams complaining that the effort to release a spec is too much. I took a look at our TCK process again. When there is a TCK challenge that is accepted, we just say there needs to be an immediate release of the TCK along with any exclude list changes. When dropping/excluding a test, there should not be a need for a CCR as the scope of the TCK has reduced.
If a platform wants to state runtime requirements, I agree that those requirements should be validated at the platform TCK level. However, if there are standalone TCKs being run as part of the platform, at some point there is likely a change going to be needed in that standalone TCK to run on the platform runtime. At that point the requirement is going to have to be fed into the project.
After reading Ed's email to the lists about CCR requirements for 9.1, the notion of 'standalone' TCKs is a bit confusing because most of the standalone TCKs listed have their source in the CTS repository. It just happens to be packaged up for release separate from the CTS.
For truly independent TCKs that have their source separate from the CTS, if the platform runtime requirement change does not require a new release of the TCK binary, there should be no requirement for a CCR at the specification level. That would be a purely optional compatibility claim that the implementation wants to make. There should not be a requirement on the specification project team.
There will be times when the platform wants to move the base language level, potentially requiring specifications to update one or more of the API/specification/TCK. In that case specification projects that will be included would need to create a new major release. In that circumstance it is clear that one or more CCRs will be needed to validate the release.
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
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec