Re: [jakartaee-tck-dev] Initial appclient protocol

[Scott Stark <starksm64@xxxxxxxxx>]

Looks good to me!

On Thu, Jun 27, 2024 at 12:49 PM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>
>
>
> On Wed, Jun 19, 2024 at 10:05 AM Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>>
>>
>> On 6/16/24 12:05 AM, Scott Stark via jakartaee-tck-dev wrote:
>>
>> I have pushed the initial appclient protocol to my jakartaee-tck-tools
>> fork and created a PR to merge it:
>>
>> https://github.com/starksm64/jakartaee-tck-tools
>> https://github.com/eclipse-ee4j/jakartaee-tck-tools/pull/37
>>
>> There is a sample runner for WildFly that uses this appclient protocol
>> to run the com.sun.ts.tests.ejb30.bb.session.stateless.basic.Client
>> from the current tckrefactor branch of the platform-tck build of the
>> jakarta.tck:ejb30 artifact.
>>
>> The runner repo is:
>> https://github.com/jakartaredhat/wildfly-ee11-tck-runner
>>
>> In there you will find a
>> ejb30.bb.session.stateless.basic.ClientTest.java test, which is a
>> subclass of the
>> com.sun.ts.tests.ejb30.bb.session.stateless.basic.Client. The subclass
>> adds the Arquillian @Deployment method and the @Test annotation to the
>> overridden test methods.
>>
>> Generating a subclass like this without modifying the existing tests
>> may be what Scott Marlow was talking about on the call on Wednesday.
>>
>> +1
>
>
> https://github.com/jakartaee/platform-tck/pull/1344 has a draft change that shows adding new (JPA/Persistence) Platform TCK test classes to the current Maven submodule used for the JPA/Persistence 3.2 component TCK.  As mentioned on that pull request, I think we should start a new submodule for the JPA/Persistence (Platform TCK) tests.
>
> Any concerns about adding a new submodule for the JPA/Persistence Platform TCK tests?
>
> Scott
>
>>
>> I'm going to fork AddArquillianDeployMethodRecipe into a new recipe GenerateNewTestClassRecipe that will extend the current test classes.
>>
>> We might want to also look into delegation for the cases that there are multiple test client classes currently (e.g. https://github.com/jakartaee/platform-tck/blob/tckrefactor/jpa/spec-tests/src/main/java/ee/jakarta/tck/persistence/core/StoredProcedureQuery/Client.java extends PMClientBase and https://github.com/jakartaee/platform-tck/blob/tckrefactor/jpa/spec-tests/src/main/java/ee/jakarta/tck/persistence/core/StoredProcedureQuery/Client1.java extends Client as does Client2.java).
>>
>> Being able to use the existing JavaTest classes without modification
>> is what I'm looking at doing for the other vehicles.
>>
>> +1
>>
>> Ideally the combination of the ant parser code in the
>> jakartaee-tck-tools in combination with the openrewrite rules will
>> allows us to generate Aquillian/Junt5 subclasses for all of the EE 10
>> tests.
>>
>> Take a look at modifying the wildfly-ee11-tck-runner.git for your
>> appclient setup and create issues on the jakartaee-tck-tools repo for
>> any issues with the appclient protocol.
>>
>> 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
>>