You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by David Blevins <da...@gmail.com> on 2021/04/16 09:29:19 UTC
CXF-7996 Jakarta EE TCKs and compatibility
Hi All,
Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
- https://github.com/tckwork/cxf
If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
- https://issues.apache.org/jira/browse/CXF-7996
The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
-David
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by David Blevins <da...@gmail.com>.
> On Apr 30, 2021, at 11:09 AM, David Blevins <da...@gmail.com> wrote:
>
> There's a bunch of tests that got fixed because we weren't properly getting the classes a MessageBodyReader or Writer supports via it's generic declaration. So there's a handful of tests that are fixed, but not explicitly called out by JIRA in the commit history of my branch. I think this makes it harder for others to contribute because of not knowing which tests are still broken. That has me second guessing my "too early for a PR" statement.
>
> I can think of two ways to approach this:
>
> - We just merge to master and deal with any breakage in master.
> - We spin off a branch and both work there. We deal with the breakage and detailed reviewing before it's merged to master.
I created a PR so if we want to do either of these, we can.
- https://github.com/apache/cxf/pull/783
No expectation that we actually do any of it. I'm also putting the fixes here, so from a TomEE perspective we're fine and there's no time pressure:
- https://github.com/apache/tomee-jakarta/tree/master/transform/src/patch/java/org/apache/cxf
We can merge at any time with any amount of rework before and/or after a merge.
-David
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by David Blevins <da...@gmail.com>.
> On Apr 30, 2021, at 4:36 AM, Andriy Redko <dr...@gmail.com> wrote:
>
> Thanks a lot for the update and leading the effort, the timelines are pretty rough!
Indeed. Not a lot of sleeping going on! But there is plenty of excitement, so that's good :)
> Anyway I have a fix for [1], will submit the PR shortly.
>
> [1] https://issues.apache.org/jira/browse/CXF-8518
Oh that's awesome. That test was kicking my butt so I moved on to others. What a relief.
There's a bunch of tests that got fixed because we weren't properly getting the classes a MessageBodyReader or Writer supports via it's generic declaration. So there's a handful of tests that are fixed, but not explicitly called out by JIRA in the commit history of my branch. I think this makes it harder for others to contribute because of not knowing which tests are still broken. That has me second guessing my "too early for a PR" statement.
I can think of two ways to approach this:
- We just merge to master and deal with any breakage in master.
- We spin off a branch and both work there. We deal with the breakage and detailed reviewing before it's merged to master.
Either way we'd probably want to duplicate the TCK job to point at the branch as I'm not sure aggressively merging to the "fixes" branch makes any of us too comfortable.
Thoughts?
-David
>
> DB> General update. I'm cranking through fixes in a branch here:
>
> DB> - https://github.com/dblevins/cxf/commits/tckfixes
>
> DB> I'm hesitant to submit a PR just yet as this branch isn't really "cold" yet. Still another 10 or so fixes that are needed on the TomEE side that all need to be done in the next 48 hours for us to make the EE 9.1 release. Meanwhile, wanted to give everyone a heads up so there isn't just one big surprising PR. I mean, it'll still be big, but at least not surprising :)
>
> DB> Thanks again to Andriy and Andy for all the support! I'd never have gotten this far without either of you.
>
>
> DB> -David
>
>
>>> On Apr 16, 2021, at 2:29 AM, David Blevins <da...@gmail.com> wrote:
>
>>> Hi All,
>
>>> Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
>
>>> Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
>
>>> Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
>
>>> - https://github.com/tckwork/cxf
>
>>> If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
>
>>> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
>
>>> - https://issues.apache.org/jira/browse/CXF-7996
>
>>> The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
>
>>> If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
>
>
>>> -David
>
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by Andriy Redko <dr...@gmail.com>.
Hi David,
Thanks a lot for the update and leading the effort, the timelines are pretty rough!
Anyway I have a fix for [1], will submit the PR shortly.
[1] https://issues.apache.org/jira/browse/CXF-8518
Best Regards,
Andriy Redko
DB> General update. I'm cranking through fixes in a branch here:
DB> - https://github.com/dblevins/cxf/commits/tckfixes
DB> I'm hesitant to submit a PR just yet as this branch isn't really "cold" yet. Still another 10 or so fixes that are needed on the TomEE side that all need to be done in the next 48 hours for us to make the EE 9.1 release. Meanwhile, wanted to give everyone a heads up so there isn't just one big surprising PR. I mean, it'll still be big, but at least not surprising :)
DB> Thanks again to Andriy and Andy for all the support! I'd never have gotten this far without either of you.
DB> -David
>> On Apr 16, 2021, at 2:29 AM, David Blevins <da...@gmail.com> wrote:
>> Hi All,
>> Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
>> Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
>> Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
>> - https://github.com/tckwork/cxf
>> If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
>> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
>> - https://issues.apache.org/jira/browse/CXF-7996
>> The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
>> If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
>> -David
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by David Blevins <da...@gmail.com>.
General update. I'm cranking through fixes in a branch here:
- https://github.com/dblevins/cxf/commits/tckfixes
I'm hesitant to submit a PR just yet as this branch isn't really "cold" yet. Still another 10 or so fixes that are needed on the TomEE side that all need to be done in the next 48 hours for us to make the EE 9.1 release. Meanwhile, wanted to give everyone a heads up so there isn't just one big surprising PR. I mean, it'll still be big, but at least not surprising :)
Thanks again to Andriy and Andy for all the support! I'd never have gotten this far without either of you.
-David
> On Apr 16, 2021, at 2:29 AM, David Blevins <da...@gmail.com> wrote:
>
> Hi All,
>
> Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
>
> Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
>
> Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
>
> - https://github.com/tckwork/cxf
>
> If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
>
> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
>
> - https://issues.apache.org/jira/browse/CXF-7996
>
> The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
>
> If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
>
>
> -David
>
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by Andriy Redko <dr...@gmail.com>.
Hi Andy,
Yes, sure, the test suite in question is org.apache.cxf.systest.jaxrs.JAXRSSoapBookTest, in
particular the test cases which use org.apache.cxf.systest.jaxrs.BookSubresource. In the
nutshell, in case of @FormParam("") the key is empty string ("") but it is not stored
as empty string in params (rather expanded). In this case the decode check is noop
essentially since there are no values stored under empty key. Please let me know
if you need simpler test case(s), I can add a few shortly.
Thanks a lot for looking.
Best Regards,
Andriy Redko
AM> Hi Andriy,
AM> Do you have a test case that shows the problem with the empty string
AM> FormParam? It does look like it might double-decode unless we also add a
AM> check later in the method to avoid that case.
AM> Thanks for pointing this out.
AM> Andy
AM> On Sun, Apr 18, 2021 at 9:19 PM Andriy Redko <dr...@gmail.com> wrote:
>> Hey guys,
>> I was lucky enough to have time during the weekend to fix a few TCK test
>> cases caused by
>> deployment issues. @David you may be interested in backporting [1] to your
>> repository. So
>> we are down to 61 failing test cases (+2 errors related to async
>> processing if I am not
>> mistaken). Regarding master builds, I am not sure we need yet another job,
>> we usually
>> very disciplined in backporting the fixes to 3.4.x / 3.3.x.
>> @Andy I have run into the edge case with @Encoded, when parameter name is
>> empty, fe @FormParam("").
>> I believe this is not standard but CXF supports that. I came up with this
>> quick fix [2] but I am
>> not sure it won't lead to multiple decoding attempts, still looking for
>> better solution.
>> Thanks!
>> [1]
>> https://github.com/apache/cxf/commit/7b820e3f193dc6fd0d73272c646d9b9aae2a1377
>> [2]
>> https://github.com/apache/cxf/commit/3b1ddd7c5e7a450d0c768e40850e5a899a8720b3
>> Best Regards,
>> Andriy Redko
>> > Do we want another job to build master? Only mention that as I see
>> Andy's PR was merged there.
>> I just backported it to 3.4.x-fixes so that it will show up in 3.4.4.
>> Thanks,
>> Andy
>> On Fri, Apr 16, 2021 at 2:04 PM David Blevins <da...@gmail.com>
>> wrote:
>> > On Apr 16, 2021, at 4:46 AM, Andriy Redko <dr...@gmail.com> wrote:
>> > Good idea to create a subtask for each failure, personally haven't found
>> time to do that, my bad,
>> > thank you.
>> Happy to help!
>> > I will go over them and point to the relevant pull requests, some of
>> these issues
>> > have been worked on already (but not integrated yet).
>> Thank you so much.
>> > FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports
>> and jtr files + binaries,
>> > as build artifacts, for example [1].
>> I totally did miss that :) Thank you for that! I downloaded the zip and
>> it has it all right there. Nice work.
>> Do we want another job to build master? Only mention that as I see Andy's
>> PR was merged there.
>> -David
>> > [1]
>> https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
>> > Best Regards,
>> > Andriy Redko
>> > DB> Hi All,
>> > DB> Spinning a new thread as to not overload the original "@Encoded TCK
>> issue" too much.
>> > DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts.
>> Thanks also, Andy, for the link to the proper JIRA issue.
>> > DB> Here's what I've done. I converted the Jenkinsfile into a script
>> and hammered on it so it is more developer friendly. Specifically, you can
>> run one test or a chunk of tests. As well it won't redo any setup steps
>> unless needed. It calculates a sha on your cxf-core jar and if that hasn't
>> changed, it just goes straight to running the requested test. This should
>> make it easier for us to debug and work locally.
>> > DB> - https://github.com/tckwork/cxf
>> > DB> If we want this, tell me where it should go and I'll submit a PR.
>> On the TomEE side, we keep a separate repo just for the TCK setup, which is
>> kind of handy as it tends to grow over time and one setup can work for all
>> our branches. But anything works really.
>> > DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job,
>> parsed out each failing test, ran it locally, saved all the output and
>> wrote a script to create a subtask on CXF-7996 for each failing test:
>> > DB> - https://issues.apache.org/jira/browse/CXF-7996
>> > DB> The description of each subtask is the test name, a chunk of the
>> output, and instructions on how to run the test. Attached to each subtask
>> is the full TCK test output and jtr file so people can browse the failures
>> without having to run them directly. Also attached is a `test.txt` file
>> containing the test name so there is an easy way for future automated tools
>> to know what issue to update as status changes.
>> > DB> If I've possibly overstepped creating all those subtasks, let me
>> know and I can easily move them or delete them. Totally fine.
>> > DB> -David
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by Andy McCright <j....@gmail.com>.
Hi Andriy,
Do you have a test case that shows the problem with the empty string
FormParam? It does look like it might double-decode unless we also add a
check later in the method to avoid that case.
Thanks for pointing this out.
Andy
On Sun, Apr 18, 2021 at 9:19 PM Andriy Redko <dr...@gmail.com> wrote:
> Hey guys,
>
> I was lucky enough to have time during the weekend to fix a few TCK test
> cases caused by
> deployment issues. @David you may be interested in backporting [1] to your
> repository. So
> we are down to 61 failing test cases (+2 errors related to async
> processing if I am not
> mistaken). Regarding master builds, I am not sure we need yet another job,
> we usually
> very disciplined in backporting the fixes to 3.4.x / 3.3.x.
>
> @Andy I have run into the edge case with @Encoded, when parameter name is
> empty, fe @FormParam("").
> I believe this is not standard but CXF supports that. I came up with this
> quick fix [2] but I am
> not sure it won't lead to multiple decoding attempts, still looking for
> better solution.
>
> Thanks!
>
> [1]
> https://github.com/apache/cxf/commit/7b820e3f193dc6fd0d73272c646d9b9aae2a1377
> [2]
> https://github.com/apache/cxf/commit/3b1ddd7c5e7a450d0c768e40850e5a899a8720b3
>
>
> Best Regards,
> Andriy Redko
>
>
> > Do we want another job to build master? Only mention that as I see
> Andy's PR was merged there.
>
> I just backported it to 3.4.x-fixes so that it will show up in 3.4.4.
>
> Thanks,
>
> Andy
>
> On Fri, Apr 16, 2021 at 2:04 PM David Blevins <da...@gmail.com>
> wrote:
>
> > On Apr 16, 2021, at 4:46 AM, Andriy Redko <dr...@gmail.com> wrote:
>
> > Good idea to create a subtask for each failure, personally haven't found
> time to do that, my bad,
> > thank you.
>
> Happy to help!
>
> > I will go over them and point to the relevant pull requests, some of
> these issues
> > have been worked on already (but not integrated yet).
>
> Thank you so much.
>
>
> > FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports
> and jtr files + binaries,
> > as build artifacts, for example [1].
>
> I totally did miss that :) Thank you for that! I downloaded the zip and
> it has it all right there. Nice work.
>
> Do we want another job to build master? Only mention that as I see Andy's
> PR was merged there.
>
>
> -David
>
>
>
> > [1]
> https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
>
> > Best Regards,
> > Andriy Redko
>
> > DB> Hi All,
>
> > DB> Spinning a new thread as to not overload the original "@Encoded TCK
> issue" too much.
>
> > DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts.
> Thanks also, Andy, for the link to the proper JIRA issue.
>
> > DB> Here's what I've done. I converted the Jenkinsfile into a script
> and hammered on it so it is more developer friendly. Specifically, you can
> run one test or a chunk of tests. As well it won't redo any setup steps
> unless needed. It calculates a sha on your cxf-core jar and if that hasn't
> changed, it just goes straight to running the requested test. This should
> make it easier for us to debug and work locally.
>
> > DB> - https://github.com/tckwork/cxf
>
> > DB> If we want this, tell me where it should go and I'll submit a PR.
> On the TomEE side, we keep a separate repo just for the TCK setup, which is
> kind of handy as it tends to grow over time and one setup can work for all
> our branches. But anything works really.
>
> > DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job,
> parsed out each failing test, ran it locally, saved all the output and
> wrote a script to create a subtask on CXF-7996 for each failing test:
>
> > DB> - https://issues.apache.org/jira/browse/CXF-7996
>
> > DB> The description of each subtask is the test name, a chunk of the
> output, and instructions on how to run the test. Attached to each subtask
> is the full TCK test output and jtr file so people can browse the failures
> without having to run them directly. Also attached is a `test.txt` file
> containing the test name so there is an easy way for future automated tools
> to know what issue to update as status changes.
>
> > DB> If I've possibly overstepped creating all those subtasks, let me
> know and I can easily move them or delete them. Totally fine.
>
>
> > DB> -David
>
>
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by Andriy Redko <dr...@gmail.com>.
Hey guys,
I was lucky enough to have time during the weekend to fix a few TCK test cases caused by
deployment issues. @David you may be interested in backporting [1] to your repository. So
we are down to 61 failing test cases (+2 errors related to async processing if I am not
mistaken). Regarding master builds, I am not sure we need yet another job, we usually
very disciplined in backporting the fixes to 3.4.x / 3.3.x.
@Andy I have run into the edge case with @Encoded, when parameter name is empty, fe @FormParam("").
I believe this is not standard but CXF supports that. I came up with this quick fix [2] but I am
not sure it won't lead to multiple decoding attempts, still looking for better solution.
Thanks!
[1] https://github.com/apache/cxf/commit/7b820e3f193dc6fd0d73272c646d9b9aae2a1377
[2] https://github.com/apache/cxf/commit/3b1ddd7c5e7a450d0c768e40850e5a899a8720b3
Best Regards,
Andriy Redko
> Do we want another job to build master? Only mention that as I see Andy's PR was merged there.
I just backported it to 3.4.x-fixes so that it will show up in 3.4.4.
Thanks,
Andy
On Fri, Apr 16, 2021 at 2:04 PM David Blevins <da...@gmail.com> wrote:
> On Apr 16, 2021, at 4:46 AM, Andriy Redko <dr...@gmail.com> wrote:
> Good idea to create a subtask for each failure, personally haven't found time to do that, my bad,
> thank you.
Happy to help!
> I will go over them and point to the relevant pull requests, some of these issues
> have been worked on already (but not integrated yet).
Thank you so much.
> FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports and jtr files + binaries,
> as build artifacts, for example [1].
I totally did miss that :) Thank you for that! I downloaded the zip and it has it all right there. Nice work.
Do we want another job to build master? Only mention that as I see Andy's PR was merged there.
-David
> [1] https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
> Best Regards,
> Andriy Redko
> DB> Hi All,
> DB> Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
> DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
> DB> Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
> DB> - https://github.com/tckwork/cxf
> DB> If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
> DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
> DB> - https://issues.apache.org/jira/browse/CXF-7996
> DB> The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
> DB> If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
> DB> -David
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by Andy McCright <j....@gmail.com>.
> Do we want another job to build master? Only mention that as I see
Andy's PR was merged there.
I just backported it to 3.4.x-fixes so that it will show up in 3.4.4.
Thanks,
Andy
On Fri, Apr 16, 2021 at 2:04 PM David Blevins <da...@gmail.com>
wrote:
> > On Apr 16, 2021, at 4:46 AM, Andriy Redko <dr...@gmail.com> wrote:
> >
> > Good idea to create a subtask for each failure, personally haven't found
> time to do that, my bad,
> > thank you.
>
> Happy to help!
>
> > I will go over them and point to the relevant pull requests, some of
> these issues
> > have been worked on already (but not integrated yet).
>
> Thank you so much.
>
> >
> > FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports
> and jtr files + binaries,
> > as build artifacts, for example [1].
>
> I totally did miss that :) Thank you for that! I downloaded the zip and
> it has it all right there. Nice work.
>
> Do we want another job to build master? Only mention that as I see Andy's
> PR was merged there.
>
>
> -David
>
>
> >
> > [1]
> https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
> >
> > Best Regards,
> > Andriy Redko
> >
> > DB> Hi All,
> >
> > DB> Spinning a new thread as to not overload the original "@Encoded TCK
> issue" too much.
> >
> > DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts.
> Thanks also, Andy, for the link to the proper JIRA issue.
> >
> > DB> Here's what I've done. I converted the Jenkinsfile into a script
> and hammered on it so it is more developer friendly. Specifically, you can
> run one test or a chunk of tests. As well it won't redo any setup steps
> unless needed. It calculates a sha on your cxf-core jar and if that hasn't
> changed, it just goes straight to running the requested test. This should
> make it easier for us to debug and work locally.
> >
> > DB> - https://github.com/tckwork/cxf
> >
> > DB> If we want this, tell me where it should go and I'll submit a PR.
> On the TomEE side, we keep a separate repo just for the TCK setup, which is
> kind of handy as it tends to grow over time and one setup can work for all
> our branches. But anything works really.
> >
> > DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job,
> parsed out each failing test, ran it locally, saved all the output and
> wrote a script to create a subtask on CXF-7996 for each failing test:
> >
> > DB> - https://issues.apache.org/jira/browse/CXF-7996
> >
> > DB> The description of each subtask is the test name, a chunk of the
> output, and instructions on how to run the test. Attached to each subtask
> is the full TCK test output and jtr file so people can browse the failures
> without having to run them directly. Also attached is a `test.txt` file
> containing the test name so there is an easy way for future automated tools
> to know what issue to update as status changes.
> >
> > DB> If I've possibly overstepped creating all those subtasks, let me
> know and I can easily move them or delete them. Totally fine.
> >
> >
> > DB> -David
> >
>
>
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by David Blevins <da...@gmail.com>.
> On Apr 16, 2021, at 4:46 AM, Andriy Redko <dr...@gmail.com> wrote:
>
> Good idea to create a subtask for each failure, personally haven't found time to do that, my bad,
> thank you.
Happy to help!
> I will go over them and point to the relevant pull requests, some of these issues
> have been worked on already (but not integrated yet).
Thank you so much.
>
> FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports and jtr files + binaries,
> as build artifacts, for example [1].
I totally did miss that :) Thank you for that! I downloaded the zip and it has it all right there. Nice work.
Do we want another job to build master? Only mention that as I see Andy's PR was merged there.
-David
>
> [1] https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
>
> Best Regards,
> Andriy Redko
>
> DB> Hi All,
>
> DB> Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
>
> DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
>
> DB> Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
>
> DB> - https://github.com/tckwork/cxf
>
> DB> If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
>
> DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
>
> DB> - https://issues.apache.org/jira/browse/CXF-7996
>
> DB> The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
>
> DB> If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
>
>
> DB> -David
>
Re: CXF-7996 Jakarta EE TCKs and compatibility
Posted by Andriy Redko <dr...@gmail.com>.
Hi David,
Good idea to create a subtask for each failure, personally haven't found time to do that, my bad,
thank you. I will go over them and point to the relevant pull requests, some of these issues
have been worked on already (but not integrated yet).
FYI: Just a hint (if you haven't noticed) each CXF TCK run has reports and jtr files + binaries,
as build artifacts, for example [1].
[1] https://ci-builds.apache.org/job/CXF/job/CXF-JAXRS-TCK/lastSuccessfulBuild/artifact/
Best Regards,
Andriy Redko
DB> Hi All,
DB> Spinning a new thread as to not overload the original "@Encoded TCK issue" too much.
DB> Thanks, Andriy, for the Jenkins information and TCK setup scripts. Thanks also, Andy, for the link to the proper JIRA issue.
DB> Here's what I've done. I converted the Jenkinsfile into a script and hammered on it so it is more developer friendly. Specifically, you can run one test or a chunk of tests. As well it won't redo any setup steps unless needed. It calculates a sha on your cxf-core jar and if that hasn't changed, it just goes straight to running the requested test. This should make it easier for us to debug and work locally.
DB> - https://github.com/tckwork/cxf
DB> If we want this, tell me where it should go and I'll submit a PR. On the TomEE side, we keep a separate repo just for the TCK setup, which is kind of handy as it tends to grow over time and one setup can work for all our branches. But anything works really.
DB> I then downloaded the consoleText from the latest CXF-JAXRS-TCK job, parsed out each failing test, ran it locally, saved all the output and wrote a script to create a subtask on CXF-7996 for each failing test:
DB> - https://issues.apache.org/jira/browse/CXF-7996
DB> The description of each subtask is the test name, a chunk of the output, and instructions on how to run the test. Attached to each subtask is the full TCK test output and jtr file so people can browse the failures without having to run them directly. Also attached is a `test.txt` file containing the test name so there is an easy way for future automated tools to know what issue to update as status changes.
DB> If I've possibly overstepped creating all those subtasks, let me know and I can easily move them or delete them. Totally fine.
DB> -David