On 7/24/20 3:18 PM, Ed Bratt wrote: Just curious -- what is the plan for finalizing the stand-alone TCKs? I understand there is still some work going on with them -- documentation, maybe exclude lists, etc. But at some point, they need to be finalized. Certainly once a specification goes to Ballot, that TCK will need to be frozen -- even if other TCKs from this project still need work.
Are the build systems set up to start curtailing the production of TCKs once the APIs go to ballot?
If we need to make further changes to the stand-along TCKs after an API has gone to ballot, what options do we have for further test changes? "Frozen" means no changes, so I think we could defer further test changes that could impact that (gone to ballot) API until the next TCK development cycle. Are there other options?
I would expect if the testing finds issues that need to be fixed that these can be addressed as your only option is to exclude these tests.
For Java EE, we would address any late coming tests that we felt needed to fixed (sometimes due to configuration/platform issues), otherwise we would exclude. Do we have any sense of the risk that a general problem might be found, as we close out Jakarta EE 9, that might force all the TCKs to be rebuilt after some of the ballots conclude?
We talked about keeping the TCK development process open for JDK11 test changes (e.g. for non-signature test failures that we might discover with other Jakarta EE 9 server implementations). That is at risk. A smaller risk, could be that fixing Platform TCK level failures could be impacted as well (assuming that some test failure need to be addressed in the Platform TCK, rather than working around said test failure in GlassFish 6.0).
Hmmm, I would think until you stabilize the Jakarta EE 9 branch you would not allow updates outside of addressing must fix issues. Or am I mis-understanding the above? I see that Alwin is still running tests this weekend (thank you Alwin again for covering for me this week!), lets see where we are tomorrow with the Stand-Alone TCKs and discuss further how to freeze each one to meet the below schedule. If anyone has a different opinion on how we address the following schedule, please do speak up. Personally, I see the point of following the below schedule so that we avoid delays that we might get, if we separately passed the TCKs after an API goes to ballot and the impact that has on other dependent APIs. Scott As a reminder, these stand-alone TCKs are generated in this project (in wave sequence):
* Wave 0 (Any time)
o Concurrency
o Messaging
o Persistence
o (From the Platform TCK)
+ Web Services Metadata
* Wave 1 (Any time)
o Annotations
o _expression_ Language
o JSON Processing
o Servlet
o SOAP with Attachments
o WebSocket
* Wave 2 (Planned to start July 28)
o Authentication
o Authorization
o JSON Binding
o Server Pages
* Wave 3 (Planned to start Aug 5)
o XML Web Services
* Wave 4 (Planned to start Aug 11)
o RESTful Web Services
o Transaction
* Wave 5 (Planned to start Aug 18)
o Connectors
o Standard Tag Library
o (From the Platform TCK)
+ Enterprise Beans
+ Enterprise Web Services
* Wave 6 (Planned to start Aug 25
o Security
o Server Faces
* Wave 7 (Planned to start Aug 31)
o Jakarta EE Web Profile
o Jakarta EE Platform
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering 1 Network Drive Burlington, MA 01803Lance.Andersen@xxxxxxxxxx
|
