Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-spec-project-leads] TCK Development


On Tue, 20 Oct 2020 at 03:57, Andy McCright <j.andrew.mccright@xxxxxxxxx> wrote:
Is Servlet 5.1 the plan for EE10?  If so, could we create an EE10 branch (or rename the branches so the current master says EE9, and then make EE10 the new master)?


That has not been decided yet. It might be, or it might be 5.2 or a later version depending on timing.

I guess one option would be to branch each platform version of the TCK repo, and then have master be where all development happens, but it has the potential to be a mess if the next platform needs older versions of some specs. 
 
In JAX-RS we have a few items that we'd like to put into the TCK that are post-EE9 too (one of them also deals with SameSite cookies).  If other projects have post-EE9 changes that they want to put into the TCK it might get messy if we create a branch for each.  One "post-EE9" branch for all projects might be more manageable.


That is why we are talking about 'repo for each', with the intention being that you will only modify the classes in your spec to make it easy to merge back into the main repo.

Stuart
 
Thanks,
Andy

On Mon, Oct 19, 2020 at 5:54 AM Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:


On Mon, 19 Oct 2020 at 20:51, Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

Stuart,

I think split option 3 into 3a) servlet-tck-repo that is regularly merged back into main repo ;  3b) servlet-tck-repo that diverges from main TCK repo.


Yea, I should have been more clear that there were two different approaches you could take here. In terms of the 'merge back' I assume it will happen for platform releases, so the main repo always tracks a platform release.
 
I think that we should start with 3a) as it allows progress to be made immediately.     I think that ultimately 3b) is where we want to go but that it will need some careful thought and coordination etc.    But the good thing 3a) is a good starting point to get to 3b)

3a would be my personal preference.

Stuart
 

cheers






On Mon, 19 Oct 2020 at 02:53, Stuart Douglas <sdouglas@xxxxxxxxxx> wrote:
Hi Everyone,

Now that Servlet 5.0 is out we are looking to do a relatively quick Servlet 5.1 to get SameSite cookie support into the spec. Adding this to the spec is relatively simple, however we will also need to update the TCK and I am not really sure how the development process for updating specs will work with the current monorepo.

The way I see if there are a few different options:

1) Everyone just commits to master in the TCK repo.

This will make a huge mess, with master being a mis-mash of different specs in different stages of completion. IMHO this is a complete non starter.

2) We get a servlet-5.1 branch in the TCK repo

We do all the work in this branch, which means that all pull requests will be mixed in with other projects pull requests. It will also lead to branch explosion over time, as every version of every spec will get its own branch. Work would be pulled back into master when it is complete (or possibly based on other criteria, like a new platform release).

3) We create a new repo just for Servlet

Basically we fork the TCK repo into a servlet-tck repo, and do all our work there (which means PRs and review are handled by the Servlet project). Once the work is complete it will possibly be merged back into the main repo as required, or alternatively we could say that the Servlet TCK is now standalone, and no longer part of the main repo. This would potentially allow us to modernise it (e.g. move to Arquillian), but if we don't have time to do this the potential worst case would be that the TCK's diverge over time, resulting in lots of slightly different Javatest based TCK's with slightly different requirements/setup.

I am not really sure what the best approach is here, so I thought I would see if anyone else has been thinking about this, and what people think of the different options above.

Stuart

_______________________________________________
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


--
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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

Back to the top