[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] Finalizing the TCKs
|
On 7/27/20 7:09 AM, Lance Andersen wrote:
On Jul 26, 2020, at 9:05 AM, Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
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.
Thanks, this makes sense.
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.
This also makes sense (good to have this option for "need to fix" issues).
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.
I agree that it is more important to stabilize the TCKs than attempting
adding remaining changes for JDK 11 in the next few weeks. A few weeks
ago, continuing to push on JDK 11 test changes sounded good but now
seems unneeded.
Or am I
mis-understanding the above?
Thanks, I think that you understand perfectly, thanks for the guidance!
Scott
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 <mailto: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@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx <mailto:Lance.Andersen@xxxxxxxxxx>
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev