Re: [jakartaee-spec-project-leads] Fwd: Fwd: Update regarding guidance o

["Scott Kurz" <skurz@xxxxxxxxxx>]

Thanks Scott for drafting this proposal.

 

Let me say that in spite of contributing to it I've never run the Platform TCK nor the porting kit, so I don't fully know what I'm talking about.  But to do my part moving the discussion forward let me speak up anyway (I also responded on the Jakarta Batch ML, in even a bit more detail).

 

My impression and guess is that the common deployment technology is key, whether it's Arquillian or JT Harness plus the porting kit, and that everything else is secondary.

 

That is, whether components use TestNG vs JUnit, whether the aggregate components are glued together by Maven, Ant, Gradle, or log or annotate test assertions the same... that all seems secondary.  Either differences could be mediated at the platform level independently of component specs, and/or conventions introduced to make  the job of people who do have to run the entire platform TCK against a platform impl as easy as possible.

 

In the Batch TCK we are now looking to enable Arquillian integration in the standalone TCK (as you referenced). 

 

If every spec component were going to adopt Arquillian, then maybe the most fundamental problem is solved.

 

But if not, and the platform TCK still defines some other deployment abstraction like JT Harness using the "porting kit", or something else, then it seems the choices would be:  

 1) adapt Arquillian to the JT Harness porting deployment abstractions, either a) in the Batch TCK and/or b) in the platform TCK
 2) have the executor of the platform TCK setup and run Batch in a custom manner (via Arquillian, etc.)
 3) continue forking (possibly updating the fork to any new changes).
 
Maybe I was a bit verbose there but the point I was trying to show is I'm not sure any of those options are either a net gain for the Batch TCK contributors and/or the platform TCK executors, or are necessarily even moving incrementally in the right direction.

 

However, maybe it would be a step forward if the goal were to create a whole set of Arquillian-based TCKs, i.e. a new TCK pattern.     So option 2) above wouldn't require running Batch as one more uniquely-configured TCK but only one more Arquillian-TCK.  The platform TCK executor would have to run the Arquillian set, the custom standalone TCKs, and the remaining JT Harness / porting kit TCKs.     (And maybe everyone was already assuming this but I didn't see this spelled out.)

 

If this seems like a valuable approach then Batch can go ahead and make the move to JUnit5 + Arq that we'd been looking at, delete the Batch tests from the Platform TCK, and continue to try to stay aligned with whatever conventions we come up with at the broader level.  (If I'm oversimplifying and some of these conventions need to be solidified sooner well, I probably wouldn't realize that and would need to hear that feedback more from others).

 

That all said, I hesitate to make any changes without understanding the vision for the bigger picture here, so look forward to working this out.

------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

 

 

----- Original message -----
From: Scott Marlow <smarlow@xxxxxxxxxx>
Sent by: "jakartaee-spec-project-leads" <jakartaee-spec-project-leads-bounces@xxxxxxxxxxx>
To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Cc: Gurunandan <gurunandan.rao@xxxxxxxxxx>
Subject: [EXTERNAL] [jakartaee-spec-project-leads] Fwd: Fwd: Update regarding guidance on how to produce standalone TCKs for Jakarta EE 10...
Date: Wed, Jun 16, 2021 10:19 AM
 

Hi,

Since last week, we got more feedback on the below [2] document.  We also had some discussion during the Jakarta EE Platform call yesterday as well [3]. 

One quote from Scott Stark: "Main issue is just maintainability to make it easier for new people to work on tcks." which I think really defines one purpose behind all of the work that we will do together to move Specification specific tests from the Platform TCK to a Specification specific TCK.

The other driving force is to simplify the Specification Ballot process for many of the Specifications.  Each Specification that takes control of their TCK tests will not have to block on the Platform TCK team in order to proceed through the Spec ballot process. 

At a high level, the revised Platform TCK will likely use Apache Maven instead of Apache Ant.  Will use JUnit5 or TestNG for each test group.  We will also likely use Arquillian for deploying tests to EE containers where the test archives will be dynamically modified to include vendor specific deployment descriptors (perhaps via an Arquillian extension TBD).  Feedback is welcome from all. 

One concern that came up during the Platform call is that the EE implementations will need to deal with the Platform TCK changes but I think we all share that pain (I certainly will be busy with that for WildFly).

Thoughts?

Scott

[3] https://docs.google.com/document/d/1EJ2ilaPhMnQqa3aw6AmwjRbBPGL3_np4uuwklgfqPZI/edit?pli=1#

-------- Forwarded Message --------

Subject:	Fwd: Update regarding guidance on how to produce standalone TCKs for Jakarta EE 10...
Date:	Wed, 9 Jun 2021 08:48:59 -0400
From:	Scott Marlow <smarlow@xxxxxxxxxx>
To:	jakartaee-tck developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>

I blind copied the TCK mailing list on the below but that went into moderation since blind copying to a Jakarta EE mailing list is not allowed, so forwarding instead. 

For feedback specific to our plan for the Jakarta EE 10/10.1 (version is not certain yet) Platform TCK, please respond here on jakartaee-tck-dev@xxxxxxxxxxx.  So what is the plan exactly for the Jakarta EE 10/10.1 Platform TCK?  That is what we need to figure out soon so we can get started and be able to deliver the Platform TCKs. 

So, what are the requirements for the EE 10/10.1 Platform TCK?  Please see some ideas in [2].  The [2] `Platform TCK Plan` section talks about updating all of the existing Platform TCK tests to use TestNG or JUnit5 but that may not be possible to accomplish in a reasonable time period (not that we have a target date for the Jakarta EE 10/10.1 Platform yet.)  Another idea could be to integrate multiple test frameworks (Java Test Harness, TestNG, JUnit5) to be used for running Platform TCK tests (perhaps with a mix of using Arquillian for test deployment/control).  Any other ideas?

IMO, the overall goal should be to come up with a plan to produce the expected Platform TCKs so that Jakarta EE 10/10.1 Platform can be released after passing one or more compatible implementations. 

I suggest that we have some (recorded) meetings so we can all sync up on the plan.  We also need to figure out who will provide the expertise on the different technologies to be integrated.

I also think that now would be an awesome time to record an interview with anyone that worked on refactoring TCKs from using multiple Make tools, to instead use Apache Ant.  And get their recommendation on the different paths that might get us to having working EE 10 Platform TCKs that can be reasonably run by various EE 10/10.1 implementations.  Lance?  Others?

Lastly, just to summarize why we are having a discussion on the Platform + TCK mailing lists.  The Platform discussion is for getting input on any aspect but also is for determining the Platform level requirements for the TCK changes.  The TCK discussion is also for getting input on any aspect but will turn into a plan that describes how we will produce the Jakarta EE 10/10.1 Platform TCKs.  There is also overlap of the planning with the different Specification teams that will be moving some Standalone tests into their Specification project (please think of common Maven artifacts being produced by Platform TCK that Standalone Specifications will consume and the Platform TCK will consume TCK test artifacts from the Standalone Specifications).

Nothing is cast in stone yet, so please share your ideas for moving forward.  Feedback/help is welcome in [2] as well!

Scott

-------- Forwarded Message --------

Subject:	Re: Update regarding guidance on how to produce standalone TCKs for Jakarta EE 10...
Date:	Tue, 8 Jun 2021 13:45:18 -0400
From:	Scott Marlow <smarlow@xxxxxxxxxx>
To:	jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>

BCC: jakartaee-tck-dev@xxxxxxxxxxx

[2] links to a proposal on producing Jakarta EE 10 standalone TCKs.  Everyone with a google account should have the ability to comment on the document.  I know that some Specification teams are looking at using different test harnesses (TestNG, JUnit5 and some testing with EE containers) which are mentioned as options in [2]. 

IMO, there are unknown costs to updating the Platform TCK to work with different test harnesses but if we get volunteers to help integrate different test harnesses, that will reduce the time to release a Platform TCK based on EE 10.  I'm speaking to everyone reading this email, you don't have to be a Platform TCK committer to jump in and help us reach the Platform TCK milestone1 goal mentioned in [2].

Scott

[2] https://docs.google.com/document/d/1yDXTUUULUrFrUi1DV_9OcBKIiZLVxrZkA38MMvYdP-U/edit#

_______________________________________________
jakartaee-spec-project-leads mailing list
jakartaee-spec-project-leads@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-spec-project-leads