Re: [jakartaee-tck-dev] Comparison of the servlet test changes in the tc

[Scott Stark <starksm64@xxxxxxxxx>]

No, the work you did is definitely helping identify what is needed and
what can be automated and what looks to be more difficult with that.
The reason I made this comparison is both to set the scope of a
potential automatic translation of the remaining tests, and to provide
a before and after dataset as input into an AI learning stack. Someone
has offered to investigate whether this is a suitable translation for
their AI model, but they needed a concise set of data to look at.

On Wed, May 31, 2023 at 7:30 PM Olivier Lamy <olamy@xxxxxxxxxxx> wrote:
>
> Hi
> That's a good inventory.
> The difference you mention for httpsessionlistener.
> Is it the only one to fix? or you found a few more?
> TBH I do not see the jar name as being a problem, it's just a jar name which could be anything random :)
> But if you think it should be fixed, I can.
> The other change (classes from a jar to WEB-INF/classes or from WEB-INF/classes to a jar) as you mentioned the specs doesn’t mention any differences for this.
> This common jar just contains utilities used by almost all the wars but nothing else.
> Same can be changed as well but it was more convenient than repeating adding classes.
>
> As you noticed there is a difference of 45 in the number of tests runned using @Test and found via parsing @testName from sources (there is a maven plugin to help just in case https://github.com/jetty-project/tck-extract-tests-maven-plugin).
> The reason for this difference is the package com.sun.ts.tests.servlet.ee
> This package contains some tests not servlet only. I was not sure where to move those files.
>
> Does it mean everything I did will go to the bin?
>
> I would be happy to participate in the call but it needs to be AEST tz friendly.
>
>
> On Thu, Jun 1, 2023 at 3:47 AM Scott Stark <starksm64@xxxxxxxxx> wrote:
>>
>> As part of the effort to see what can be automated in the
>> transformation of the JavaTest based tests to Junit5/Arquillian, Scott
>> Marlow and I have created two derivative branches of the tckrefactor
>> branch of the platform tck repo in the following fork repo:
>>
>> https://github.com/jakartaredhat/platform-tck-refactor.git
>>
>> In this fork there are two branches:
>> * pre-servletupdate - this is a trimmed down version of the
>> tckrefactor that only contains the servlet TCK based tests and
>> supporting modules that are required to build the servlet tests. This
>> is using the JavaTest framework.
>> * servletupdate - this is a trimmed down version of the tckrefactor
>> that only contains the servlet TCK based tests and supporting modules
>> that are required to build the servlet tests. This is using the
>> Junit5/Arquillian framework changes that Oli made.
>>
>> The pre-servletupdate branch also contains a war-info.txt file
>> describing the contents of the test artifact in each of the test
>> packages. The purpose of this is to collapse the ant build.xml
>> information into a single file that better compares to the @Deployment
>> methods of the servletupdate branch.
>>
>> That information was generated from the EE10 tck dist bundle via a
>> Jar2Shrinkwap tool the Scott's have created in the following
>> jakartaee-tck-tools repo:
>>
>> https://github.com/scottmarlow/jakartaee-tck-tools
>>
>> The document that compares the two branches is the README-javatest.md
>> in the pre-serlvetupdate branch:
>> https://github.com/jakartaredhat/platform-tck-refactor/blob/pre-servletupdate/README-javatest.md
>>
>> It is large because I included a scan of all of the locations marked
>> with the @testName javadoc tag to have a way to compare against the
>> @Test Junit5 usage in the servletupdate branch.
>>
>> We are also working on an automation approach using the openrewrite
>> project. Right now a sticking point is the handling of the test
>> artifacts. These are built via ant and the build.xml heirarchy in the
>> JavaTest regime, and folding these into a Arquillian deployment method
>> is a little tricky. We think we can stub out most of it using
>> information from the previous TCK bundle and the Jar2Srhinkwrap tool,
>> but it seems at this point as though there will have to be a stub
>> method to fill in whenever a test has included additional embedded
>> artifacts in the WEB-INF/lib directory as an example.
>>
>> We can discuss in more detail on this thread or the June tck developer call.
>>
>> Scott
>> _______________________________________________
>> jakartaee-tck-dev mailing list
>> jakartaee-tck-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
>
>
>
> --
> Olivier
> _______________________________________________
> jakartaee-tck-dev mailing list
> jakartaee-tck-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev