Re: [jakartaee-tck-dev] Updating the TCK for javax -> jakarta transition

[Scott Marlow <smarlow@xxxxxxxxxx>]

On Mon, Jan 27, 2020 at 10:31 AM Alwin Joseph <alwin.joseph@xxxxxxxxxx> wrote:
>
> My comments/suggestions :
>
> -Make all the changes in the master branch for TCKs in https://github.com/eclipse-ee4j/jakartaee-tck for testing.

+1 for using the TCK master branch.

>
> -The jakarate-tck 8.0.2 version is already a new tag. All the transition changes can hence be moved as branch/tag 9.0.0 later ?

Yes, I agree that tagging/branching 9.0.0 can be later.

>
> -This commit can be refered on how to bump up the TCK version. This was done for 8.0.2 where the TCKs had undergone a change. This needs to be done for javax -> jakarta transition changes too.

+1

>
> -Below jobs are currently specific to the master https://github.com/eclipse-ee4j/jakartaee-tck repo.
>
> https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-build-master/ - builds the jakartaeetck bundle and copies at https://download.eclipse.org/ee4j/jakartaee-tck/master/nightly/
> https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-nightly-run-master/ - runs the full profile jakartaeetck tests using the bundle copied at the above location.
> https://ci.eclipse.org/jakartaee-tck/job/standalonetck-nightly-build-run-master/ - builds & runs standalone TCKs ( should probably try to provide option to choose the individual TCKs too )
>
> Also jobs do not run when a PR is submitted in jakartaee-tck repo. I believe it would be easier if we had that option.

At the time that a TCK pull request is made, how do we get the
GlassFish build that should be used for the TCK testing?

Or should we defer testing the pull request until the nightly
GlassFish build has the corresponding EE 9 changes?

>
> Regards,
> Alwin
>
> On 25/01/20 6:32 AM, Bill Shannon wrote:
>
> I sure would like to know that there's a plan and that we're all following it.
>
> Has the major number of the TCK repository been bumped to the next major
> version?
>
> Is the TCK repository open for javax->jakarta changes?
>
> How do we test that those changes are correct?  In cases where there's a
> standalone TCK I suppose we can generate a new version of the standalone
> TCK and test a standalone implementation with it.
>
> How do we test that the CTS changes are correct?  I suppose we need to
> generate a new version of GlassFish and test GlassFish with this new version
> of the CTS.
>
> How many CI jobs are going to be broken while we go through this transition?
>
>
> Mark Thomas wrote on 1/20/20 6:07 AM:
>
> Ping.
>
> Absent any guidance, the plan I intend to follow for each of the
> specifications I am involved in (WebSocket, EL, JSP, Servlet) is to:
>
> 1. Follow the guide on the wiki to build the stand-alone TCK.
>
> 2. Using the milestone releases of the API project(s) and Apache Tomcat
> as the implementation, figure out what I need to change to get the
> stand-alone TCK to pass with a Jakarta EE 9 implementation.
>
> 3. Submit a PR with those changes.
>
> Confirmation this is the right thing to do or corrections if it isn't
> would be much appreciated.
>
> I intend to start with the EL TCK.
>
> Mark
>
>
>
> On 08/01/2020 18:18, Bill Shannon wrote:
>
> Like Mark, I'd like to know where and how to contribute changes for the
> javax -> jakarta transition.
>
> Are we putting those changes in the master branch, or is that still reserved
> for exclude list updated for Jakarta EE 8?
>
> Are we putting those changes in some new "9.0.0" branch?
>
> Of course, this ties into GlassFish as well, so I'll need to ask the same
> question on the GlassFish list.  The update platform TCK will need an updated
> GlassFish to test against.
>
> It would probably ne nice if there was some coordination between how we handle
> branching, etc. for these two projects for Jakarta EE 9.
>
> Thanks.
>
>
> Mark Thomas wrote on 1/8/20 2:40 AM:
>
> Hi,
>
> I'm working on migrating a number of projects from javax to jakarta for
> Jakarta EE 9.
>
> What, if anything, is the TCK project expecting from the individual
> projects to help the TCK project with the transition?
>
> Can we use Jakarta EL as an explicit example?
>
> I'd be happy to try and put together a PR if I knew what was required.
>
> Thanks,
>
> Mark
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>
>
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev