[GitHub] [myfaces] pnicolucci merged pull request #330: MYFACES-4474: remove setType validation
pnicolucci merged PR #330: URL: https://github.com/apache/myfaces/pull/330 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] dependabot[bot] opened a new pull request, #3342: build(deps): bump tomcat.version from 9.0.67 to 9.0.68
dependabot[bot] opened a new pull request, #3342: URL: https://github.com/apache/myfaces-tobago/pull/3342 Bumps `tomcat.version` from 9.0.67 to 9.0.68. Updates `tomcat-el-api` from 9.0.67 to 9.0.68 Updates `tomcat-jasper-el` from 9.0.67 to 9.0.68 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[VOTE] Release Tobago 5.3.0 and checkstyle-rules 19
Hello, we would like to release: * Tobago 5.3.0 * checkstyle-rules 19 The artifacts were deployed on nexus repository for binary and source packages: * Tobago 5.3.0 & checkstyle-rules 19 [1] The release notes are in Jira: * Tobago 5.3.0 [2] The artifacts are available at the staging repository (Nexus) at: * Tobago 5.3.0 [3] (sha-256 689f3bd11deef4e758d5c07f7eaa78bba93192a64b5d8f06c61af52d0fe2e83c) * checkstyle-rules 19 [4] (sha-256 fd086c62bfecc5dd41ae7ef76e97907c7dace35c4984ece9bd1db194971176af) Please vote now! (The vote is open for 72h.) [ ] +1 [ ] +0 [ ] -1 Regards, Udo [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1212 [2] https://issues.apache.org/jira/projects/TOBAGO/versions/12350747 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-1212/org/apache/myfaces/tobago/tobago/5.3.0/tobago-5.3.0-source-release.zip [4] https://repository.apache.org/content/repositories/orgapachemyfaces-1212/org/apache/myfaces/buildtools/checkstyle-rules/19/checkstyle-rules-19-source-release.zip
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3341: Tobago 5.x cve2
lofwyr14 merged PR #3341: URL: https://github.com/apache/myfaces-tobago/pull/3341 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3340: build: update because of CVEs
lofwyr14 merged PR #3340: URL: https://github.com/apache/myfaces-tobago/pull/3340 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3339: build: update because of CVEs
lofwyr14 merged PR #3339: URL: https://github.com/apache/myfaces-tobago/pull/3339 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 opened a new pull request, #3338: build: ignore problems in spring boot
lofwyr14 opened a new pull request, #3338: URL: https://github.com/apache/myfaces-tobago/pull/3338 because its not part of the release -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3338: build: ignore problems in spring boot
lofwyr14 merged PR #3338: URL: https://github.com/apache/myfaces-tobago/pull/3338 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3337: Tobago 5.x prep
lofwyr14 merged PR #3337: URL: https://github.com/apache/myfaces-tobago/pull/3337 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: faces_ts integration tests
For me the more unit tests the better no matter what the technology :) On 10/7/2022 7:15 AM, Werner Punz wrote: Hi thanks, then I will prepare a pull request. Expect it early/mid next week. You still can decide whether you want to take it in or not, then. Werner Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware : I am totally find without Arquillian as well. On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote: For me it's fine without Arquilian Udo Am 07.10.22 um 09:56 schrieb Werner Punz: Hi, given I have not gotten any answer! Do you guys want the tests within MyFaces or is Arquilian an absolute must? Werner Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz : Hi, I just wanted to get feedback on the following: Atm we have a barebones Ajax integration test in our integration test system, derived from my github based integration testsuite. Problem is a) It is barebones, and basically just the basic tests, which is mostly test 1 of my suite, also it needs lots of code for maintenance. b) The current aquilian installation makes problems ( have not spent too much time fixing this, i just filed a bugreport for now) c) The new codebase uses already a ton of mocha based unit tests on ts level I have my own set of atm 19 integration tests, which I run against my codebase. The issue is, that this testcase uses mocha in the pages to collect the test data and to run the tests with a well known api. And in the backend a server is running providing beans and response. The test results are collected client side. Given the troubles I had with Aquilian, I have extended my codebase on Github so that the tests automatically run with an embedded chrome via the maven frontend plugin and also the frontend plugin hooks the test results into the maven build So basically internally maven starts an embedded tomcat viay the exec plugin and the frontend plugin pushes an embedded windowless chrome against this code to run the tests and collect the results, and reports them back to Maven in the integration test phase ... [INFO] http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf [INFO] Page test10-doubleeval Successes: [INFO] => Regression test for double eval on a single script element [INFO] => Runs the double eval test [INFO] ✔ double evaluation of embedded scripts testcase (281ms) [INFO] http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf [INFO] Page test11-scriptblocks Successes: [INFO] => Script blocks in various formats [INFO] => Performs a script bloc test ... [INFO] => Execute none handling [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute @none [INFO] ✔ execute parameter test (281ms) [INFO] [INFO] [INFO] 19 passing (23s) [INFO] [INFO] [INFO] --- maven-failsafe-plugin:2.12:verify (default) @ IntegrationJSTest --- This how it looks if all tests have passed or in case of a failure: [INFO] 18 passing (23s) [INFO] 1 failing [INFO] [INFO] 1) Integration Testsuite MyFaces [INFO] testing viewRoot: [INFO] [INFO] AssertionError: expected false to be true [INFO] + expected - actual [INFO] [INFO] -false [INFO] +true [INFO] [INFO] at Context. (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28) [INFO] at processTicksAndRejections (node:internal/process/task_queues:96:5) [INFO] [INFO] [INFO] [INFO] [INFO] BUILD FAILURE [INFO] The config is as follows: The advantage is that the tests are now way easier to write and hook themselves perfectly into the client side unit test system. Next advantage you also can run the tests directly in your browser and you also can show a browser instead of an headless embedded chrome. We also would get 17-18 additional integration tests "for free" in the myfaces codebase, simply because I have them already written a long time ago. The disadvantage is (whether this really is one) we bypass Aqulian in favor of the frontend plugin node and
Re: faces_ts integration tests
Hi thanks, then I will prepare a pull request. Expect it early/mid next week. You still can decide whether you want to take it in or not, then. Werner Am Fr., 7. Okt. 2022 um 13:04 Uhr schrieb Melloware : > I am totally find without Arquillian as well. > > > On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote: > > For me it's fine without Arquilian > > Udo > Am 07.10.22 um 09:56 schrieb Werner Punz: > > Hi, given I have not gotten any answer! > Do you guys want the tests within MyFaces or is Arquilian an absolute must? > > > Werner > > > Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz < > werner.p...@gmail.com>: > >> Hi, >> I just wanted to get feedback on the following: >> Atm we have a barebones Ajax integration test in our integration test >> system, derived from my github based integration testsuite. >> Problem is >> a) It is barebones, and basically just the basic tests, which is mostly >> test 1 of my suite, also it needs lots of code for maintenance. >> b) The current aquilian installation makes problems ( have not spent too >> much time fixing this, i just filed a bugreport for now) >> c) The new codebase uses already a ton of mocha based unit tests on ts >> level >> >> I have my own set of atm 19 integration tests, which I run against my >> codebase. The issue is, that this testcase uses mocha in the pages to >> collect the test data and to run the tests with a well known api. >> And in the backend a server is running providing beans and response. >> The test results are collected client side. >> >> Given the troubles I had with Aquilian, I have extended my codebase on >> Github so that the tests automatically run with an embedded chrome via the >> maven frontend plugin >> and also the frontend plugin hooks the test results into the maven build >> So basically internally maven starts an embedded tomcat viay the exec >> plugin and the frontend plugin pushes an embedded windowless chrome against >> this code to run the tests and collect the results, and reports them back >> to Maven >> in the integration test phase >> ... >> [INFO] >> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf >> [INFO] Page test10-doubleeval Successes: >> [INFO] => Regression test for double eval on a single script element >> [INFO] => Runs the double eval test >> [INFO] ✔ double evaluation of embedded scripts testcase (281ms) >> [INFO] >> http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf >> [INFO] Page test11-scriptblocks Successes: >> [INFO] => Script blocks in various formats >> [INFO] => Performs a script bloc test >> ... >> >> [INFO] => Execute none handling >> [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute >> @none >> [INFO] ✔ execute parameter test (281ms) >> [INFO] >> [INFO] >> [INFO] 19 passing (23s) >> [INFO] >> [INFO] >> [INFO] --- maven-failsafe-plugin:2.12:verify (default) @ >> IntegrationJSTest --- >> >> This how it looks if all tests have passed >> >> or in case of a failure: >> [INFO] 18 passing (23s) >> [INFO] 1 failing >> [INFO] >> [INFO] 1) Integration Testsuite MyFaces >> [INFO]testing viewRoot: >> [INFO] >> [INFO] AssertionError: expected false to be true >> [INFO] + expected - actual >> [INFO] >> [INFO] -false >> [INFO] +true >> [INFO] >> [INFO] at Context. >> (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28) >> [INFO] at processTicksAndRejections >> (node:internal/process/task_queues:96:5) >> [INFO] >> [INFO] >> [INFO] >> [INFO] >> >> [INFO] BUILD FAILURE >> [INFO] >> >> >> The config is as follows: >> >> The advantage is that the tests are now way easier to write and hook >> themselves perfectly into the client side unit test system. >> >> Next advantage you also can run the tests directly in your browser and >> you also can show a browser instead of an headless embedded chrome. >> >> We also would get 17-18 additional integration tests "for free" in the >> myfaces codebase, simply because I have them already written a long time >> ago. >> The disadvantage is (whether this really is one) we bypass Aqulian in >> favor of the frontend plugin node and mocha. >> >> I have this system working now, but as usual would perform another round >> of cleanups before merging it into myfaces, after the RC3 jsf_ts merge. >> So what´s your opinion, shall we add those tests to the codebase? I do >> not have any problem, to leave them where they are, they work fine for my >> purposes. >> >> >> Werner >> >> >>
Re: faces_ts integration tests
I am totally find without Arquillian as well. On 10/7/2022 6:54 AM, Udo Schnurpfeil wrote: For me it's fine without Arquilian Udo Am 07.10.22 um 09:56 schrieb Werner Punz: Hi, given I have not gotten any answer! Do you guys want the tests within MyFaces or is Arquilian an absolute must? Werner Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz : Hi, I just wanted to get feedback on the following: Atm we have a barebones Ajax integration test in our integration test system, derived from my github based integration testsuite. Problem is a) It is barebones, and basically just the basic tests, which is mostly test 1 of my suite, also it needs lots of code for maintenance. b) The current aquilian installation makes problems ( have not spent too much time fixing this, i just filed a bugreport for now) c) The new codebase uses already a ton of mocha based unit tests on ts level I have my own set of atm 19 integration tests, which I run against my codebase. The issue is, that this testcase uses mocha in the pages to collect the test data and to run the tests with a well known api. And in the backend a server is running providing beans and response. The test results are collected client side. Given the troubles I had with Aquilian, I have extended my codebase on Github so that the tests automatically run with an embedded chrome via the maven frontend plugin and also the frontend plugin hooks the test results into the maven build So basically internally maven starts an embedded tomcat viay the exec plugin and the frontend plugin pushes an embedded windowless chrome against this code to run the tests and collect the results, and reports them back to Maven in the integration test phase ... [INFO] http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf [INFO] Page test10-doubleeval Successes: [INFO] => Regression test for double eval on a single script element [INFO] => Runs the double eval test [INFO] ✔ double evaluation of embedded scripts testcase (281ms) [INFO] http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf [INFO] Page test11-scriptblocks Successes: [INFO] => Script blocks in various formats [INFO] => Performs a script bloc test ... [INFO] => Execute none handling [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute @none [INFO] ✔ execute parameter test (281ms) [INFO] [INFO] [INFO] 19 passing (23s) [INFO] [INFO] [INFO] --- maven-failsafe-plugin:2.12:verify (default) @ IntegrationJSTest --- This how it looks if all tests have passed or in case of a failure: [INFO] 18 passing (23s) [INFO] 1 failing [INFO] [INFO] 1) Integration Testsuite MyFaces [INFO] testing viewRoot: [INFO] [INFO] AssertionError: expected false to be true [INFO] + expected - actual [INFO] [INFO] -false [INFO] +true [INFO] [INFO] at Context. (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28) [INFO] at processTicksAndRejections (node:internal/process/task_queues:96:5) [INFO] [INFO] [INFO] [INFO] [INFO] BUILD FAILURE [INFO] The config is as follows: The advantage is that the tests are now way easier to write and hook themselves perfectly into the client side unit test system. Next advantage you also can run the tests directly in your browser and you also can show a browser instead of an headless embedded chrome. We also would get 17-18 additional integration tests "for free" in the myfaces codebase, simply because I have them already written a long time ago. The disadvantage is (whether this really is one) we bypass Aqulian in favor of the frontend plugin node and mocha. I have this system working now, but as usual would perform another round of cleanups before merging it into myfaces, after the RC3 jsf_ts merge. So what´s your opinion, shall we add those tests to the codebase? I do not have any problem, to leave them where they are, they work fine for my purposes. Werner
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3336: build: next checkstyle rules version 18
lofwyr14 merged PR #3336: URL: https://github.com/apache/myfaces-tobago/pull/3336 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: faces_ts integration tests
For me it's fine without Arquilian Udo Am 07.10.22 um 09:56 schrieb Werner Punz: Hi, given I have not gotten any answer! Do you guys want the tests within MyFaces or is Arquilian an absolute must? Werner Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz : Hi, I just wanted to get feedback on the following: Atm we have a barebones Ajax integration test in our integration test system, derived from my github based integration testsuite. Problem is a) It is barebones, and basically just the basic tests, which is mostly test 1 of my suite, also it needs lots of code for maintenance. b) The current aquilian installation makes problems ( have not spent too much time fixing this, i just filed a bugreport for now) c) The new codebase uses already a ton of mocha based unit tests on ts level I have my own set of atm 19 integration tests, which I run against my codebase. The issue is, that this testcase uses mocha in the pages to collect the test data and to run the tests with a well known api. And in the backend a server is running providing beans and response. The test results are collected client side. Given the troubles I had with Aquilian, I have extended my codebase on Github so that the tests automatically run with an embedded chrome via the maven frontend plugin and also the frontend plugin hooks the test results into the maven build So basically internally maven starts an embedded tomcat viay the exec plugin and the frontend plugin pushes an embedded windowless chrome against this code to run the tests and collect the results, and reports them back to Maven in the integration test phase ... [INFO] http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf [INFO] Page test10-doubleeval Successes: [INFO] => Regression test for double eval on a single script element [INFO] => Runs the double eval test [INFO] ✔ double evaluation of embedded scripts testcase (281ms) [INFO] http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf [INFO] Page test11-scriptblocks Successes: [INFO] => Script blocks in various formats [INFO] => Performs a script bloc test ... [INFO] => Execute none handling [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute @none [INFO] ✔ execute parameter test (281ms) [INFO] [INFO] [INFO] 19 passing (23s) [INFO] [INFO] [INFO] --- maven-failsafe-plugin:2.12:verify (default) @ IntegrationJSTest --- This how it looks if all tests have passed or in case of a failure: [INFO] 18 passing (23s) [INFO] 1 failing [INFO] [INFO] 1) Integration Testsuite MyFaces [INFO] testing viewRoot: [INFO] [INFO] AssertionError: expected false to be true [INFO] + expected - actual [INFO] [INFO] -false [INFO] +true [INFO] [INFO] at Context. (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28) [INFO] at processTicksAndRejections (node:internal/process/task_queues:96:5) [INFO] [INFO] [INFO] [INFO] [INFO] BUILD FAILURE [INFO] The config is as follows: The advantage is that the tests are now way easier to write and hook themselves perfectly into the client side unit test system. Next advantage you also can run the tests directly in your browser and you also can show a browser instead of an headless embedded chrome. We also would get 17-18 additional integration tests "for free" in the myfaces codebase, simply because I have them already written a long time ago. The disadvantage is (whether this really is one) we bypass Aqulian in favor of the frontend plugin node and mocha. I have this system working now, but as usual would perform another round of cleanups before merging it into myfaces, after the RC3 jsf_ts merge. So what´s your opinion, shall we add those tests to the codebase? I do not have any problem, to leave them where they are, they work fine for my purposes. Werner
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3335: Tobago 5.x refix
lofwyr14 merged PR #3335: URL: https://github.com/apache/myfaces-tobago/pull/3335 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3333: refactor(cleanup): remove unneeded code
lofwyr14 merged PR #: URL: https://github.com/apache/myfaces-tobago/pull/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 opened a new pull request, #3333: refactor(cleanup): remove unneeded code
lofwyr14 opened a new pull request, #: URL: https://github.com/apache/myfaces-tobago/pull/ This code ist not needed for this faces.js (only for the old jsf.js) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3332: build: update jest
lofwyr14 merged PR #3332: URL: https://github.com/apache/myfaces-tobago/pull/3332 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3331: feat: xml namespace
lofwyr14 merged PR #3331: URL: https://github.com/apache/myfaces-tobago/pull/3331 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 opened a new pull request, #3331: feat: xml namespace
lofwyr14 opened a new pull request, #3331: URL: https://github.com/apache/myfaces-tobago/pull/3331 Rename the namespaces for web.xml and web-fragment.xml to current spec. Issue: TOBAGO-2094 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3328: build(deps-dev): bump uglify-js from 3.17.2 to 3.17.3 in /tobago-theme
lofwyr14 merged PR #3328: URL: https://github.com/apache/myfaces-tobago/pull/3328 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3329: build(deps-dev): bump @types/jest from 29.1.1 to 29.1.2 in /tobago-theme
lofwyr14 merged PR #3329: URL: https://github.com/apache/myfaces-tobago/pull/3329 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] lofwyr14 merged pull request #3330: build(deps-dev): bump uglify-js from 3.17.2 to 3.17.3 in /tobago-theme
lofwyr14 merged PR #3330: URL: https://github.com/apache/myfaces-tobago/pull/3330 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] dependabot[bot] closed pull request #3327: build(deps): bump jakarta.xml.bind-api from 3.0.1 to 4.0.0
dependabot[bot] closed pull request #3327: build(deps): bump jakarta.xml.bind-api from 3.0.1 to 4.0.0 URL: https://github.com/apache/myfaces-tobago/pull/3327 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] dependabot[bot] commented on pull request #3327: build(deps): bump jakarta.xml.bind-api from 3.0.1 to 4.0.0
dependabot[bot] commented on PR #3327: URL: https://github.com/apache/myfaces-tobago/pull/3327#issuecomment-1271287125 Looks like jakarta.xml.bind:jakarta.xml.bind-api is no longer being updated by Dependabot, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] dependabot[bot] opened a new pull request, #3330: build(deps-dev): bump uglify-js from 3.17.2 to 3.17.3 in /tobago-theme
dependabot[bot] opened a new pull request, #3330: URL: https://github.com/apache/myfaces-tobago/pull/3330 Bumps [uglify-js](https://github.com/mishoo/UglifyJS) from 3.17.2 to 3.17.3. Release notes Sourced from https://github.com/mishoo/UglifyJS/releases;>uglify-js's releases. v3.17.3 Features improve heuristics for mangle.properties (3fa20866813f634d97d0958208b0bbf16977ae4d) enable domprops to be used under minify() (bd5fc4cb1b39d7a150daff1d41a5894ef217f462) improve compression of boolean conditional expressions (80fc8625476f8ce3aada091251072359b350a990, dabcc39b5138b6e9c84bfd1733bea220edee6d34, 58d997a3d68ea419147f80c066cbc8b23152f112) Bug Fixes async generator function (8e65413b992d3f0d1d1ce5829a3493c81c06d147, a570c0025141e46e795a9adf9fb318b8cf21031e) class field (e1e35163970af44c320c88ab308ad1020526faac) for await...of loop (140e4e0da881e2e92fad217586711aeb2fe6c274) lexical declaration (be8ccc3ab5c34c4d4861e58bb1634d6dbc4a53f0) switch statement (6cdc035b2f7d03baaecf87d8a83ab10c964d79ea) Commits https://github.com/mishoo/UglifyJS/commit/4a1da492ddda33dd2297fedd1684adba4fdecf85;>4a1da49 v3.17.3 https://github.com/mishoo/UglifyJS/commit/94a954c3d16a66bda16c57506afe5dfc1ddcbe6d;>94a954c minor clean-ups (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5701;>#5701) https://github.com/mishoo/UglifyJS/commit/be8ccc3ab5c34c4d4861e58bb1634d6dbc4a53f0;>be8ccc3 fix corner case in varify (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5698;>#5698) https://github.com/mishoo/UglifyJS/commit/58d997a3d68ea419147f80c066cbc8b23152f112;>58d997a fix corner case in booleans conditionals (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5696;>#5696) https://github.com/mishoo/UglifyJS/commit/dabcc39b5138b6e9c84bfd1733bea220edee6d34;>dabcc39 fix corner cases in booleans conditionals (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5695;>#5695) https://github.com/mishoo/UglifyJS/commit/140e4e0da881e2e92fad217586711aeb2fe6c274;>140e4e0 fix corner case in inline (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5693;>#5693) https://github.com/mishoo/UglifyJS/commit/80fc8625476f8ce3aada091251072359b350a990;>80fc862 enhance assignments, booleans conditionals (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5691;>#5691) https://github.com/mishoo/UglifyJS/commit/6cdc035b2f7d03baaecf87d8a83ab10c964d79ea;>6cdc035 fix corner case in if_return (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5689;>#5689) https://github.com/mishoo/UglifyJS/commit/e1e35163970af44c320c88ab308ad1020526faac;>e1e3516 fix corner case in reduce_vars (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5687;>#5687) https://github.com/mishoo/UglifyJS/commit/bd5fc4cb1b39d7a150daff1d41a5894ef217f462;>bd5fc4c implement mangle.properties.domprops (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5686;>#5686) Additional commits viewable in https://github.com/mishoo/UglifyJS/compare/v3.17.2...v3.17.3;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it
[GitHub] [myfaces-tobago] dependabot[bot] opened a new pull request, #3329: build(deps-dev): bump @types/jest from 29.1.1 to 29.1.2 in /tobago-theme
dependabot[bot] opened a new pull request, #3329: URL: https://github.com/apache/myfaces-tobago/pull/3329 Bumps [@types/jest](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/jest) from 29.1.1 to 29.1.2. Commits See full diff in https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/jest;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] dependabot[bot] opened a new pull request, #3328: build(deps-dev): bump uglify-js from 3.17.2 to 3.17.3 in /tobago-theme
dependabot[bot] opened a new pull request, #3328: URL: https://github.com/apache/myfaces-tobago/pull/3328 Bumps [uglify-js](https://github.com/mishoo/UglifyJS) from 3.17.2 to 3.17.3. Release notes Sourced from https://github.com/mishoo/UglifyJS/releases;>uglify-js's releases. v3.17.3 Features improve heuristics for mangle.properties (3fa20866813f634d97d0958208b0bbf16977ae4d) enable domprops to be used under minify() (bd5fc4cb1b39d7a150daff1d41a5894ef217f462) improve compression of boolean conditional expressions (80fc8625476f8ce3aada091251072359b350a990, dabcc39b5138b6e9c84bfd1733bea220edee6d34, 58d997a3d68ea419147f80c066cbc8b23152f112) Bug Fixes async generator function (8e65413b992d3f0d1d1ce5829a3493c81c06d147, a570c0025141e46e795a9adf9fb318b8cf21031e) class field (e1e35163970af44c320c88ab308ad1020526faac) for await...of loop (140e4e0da881e2e92fad217586711aeb2fe6c274) lexical declaration (be8ccc3ab5c34c4d4861e58bb1634d6dbc4a53f0) switch statement (6cdc035b2f7d03baaecf87d8a83ab10c964d79ea) Commits https://github.com/mishoo/UglifyJS/commit/4a1da492ddda33dd2297fedd1684adba4fdecf85;>4a1da49 v3.17.3 https://github.com/mishoo/UglifyJS/commit/94a954c3d16a66bda16c57506afe5dfc1ddcbe6d;>94a954c minor clean-ups (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5701;>#5701) https://github.com/mishoo/UglifyJS/commit/be8ccc3ab5c34c4d4861e58bb1634d6dbc4a53f0;>be8ccc3 fix corner case in varify (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5698;>#5698) https://github.com/mishoo/UglifyJS/commit/58d997a3d68ea419147f80c066cbc8b23152f112;>58d997a fix corner case in booleans conditionals (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5696;>#5696) https://github.com/mishoo/UglifyJS/commit/dabcc39b5138b6e9c84bfd1733bea220edee6d34;>dabcc39 fix corner cases in booleans conditionals (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5695;>#5695) https://github.com/mishoo/UglifyJS/commit/140e4e0da881e2e92fad217586711aeb2fe6c274;>140e4e0 fix corner case in inline (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5693;>#5693) https://github.com/mishoo/UglifyJS/commit/80fc8625476f8ce3aada091251072359b350a990;>80fc862 enhance assignments, booleans conditionals (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5691;>#5691) https://github.com/mishoo/UglifyJS/commit/6cdc035b2f7d03baaecf87d8a83ab10c964d79ea;>6cdc035 fix corner case in if_return (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5689;>#5689) https://github.com/mishoo/UglifyJS/commit/e1e35163970af44c320c88ab308ad1020526faac;>e1e3516 fix corner case in reduce_vars (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5687;>#5687) https://github.com/mishoo/UglifyJS/commit/bd5fc4cb1b39d7a150daff1d41a5894ef217f462;>bd5fc4c implement mangle.properties.domprops (https://github-redirect.dependabot.com/mishoo/UglifyJS/issues/5686;>#5686) Additional commits viewable in https://github.com/mishoo/UglifyJS/compare/v3.17.2...v3.17.3;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it
[GitHub] [myfaces-tobago] dependabot[bot] closed pull request #3326: build(deps-dev): bump jakarta.persistence-api from 3.0.0 to 3.1.0
dependabot[bot] closed pull request #3326: build(deps-dev): bump jakarta.persistence-api from 3.0.0 to 3.1.0 URL: https://github.com/apache/myfaces-tobago/pull/3326 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] dependabot[bot] commented on pull request #3326: build(deps-dev): bump jakarta.persistence-api from 3.0.0 to 3.1.0
dependabot[bot] commented on PR #3326: URL: https://github.com/apache/myfaces-tobago/pull/3326#issuecomment-1271269050 Looks like jakarta.persistence:jakarta.persistence-api is no longer being updated by Dependabot, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: faces_ts integration tests
Hi, given I have not gotten any answer! Do you guys want the tests within MyFaces or is Arquilian an absolute must? Werner Am Do., 6. Okt. 2022 um 16:22 Uhr schrieb Werner Punz : > Hi, > I just wanted to get feedback on the following: > Atm we have a barebones Ajax integration test in our integration test > system, derived from my github based integration testsuite. > Problem is > a) It is barebones, and basically just the basic tests, which is mostly > test 1 of my suite, also it needs lots of code for maintenance. > b) The current aquilian installation makes problems ( have not spent too > much time fixing this, i just filed a bugreport for now) > c) The new codebase uses already a ton of mocha based unit tests on ts > level > > I have my own set of atm 19 integration tests, which I run against my > codebase. The issue is, that this testcase uses mocha in the pages to > collect the test data and to run the tests with a well known api. > And in the backend a server is running providing beans and response. > The test results are collected client side. > > Given the troubles I had with Aquilian, I have extended my codebase on > Github so that the tests automatically run with an embedded chrome via the > maven frontend plugin > and also the frontend plugin hooks the test results into the maven build > So basically internally maven starts an embedded tomcat viay the exec > plugin and the frontend plugin pushes an embedded windowless chrome against > this code to run the tests and collect the results, and reports them back > to Maven > in the integration test phase > ... > [INFO] > http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test10-doubleeval.jsf > [INFO] Page test10-doubleeval Successes: > [INFO] => Regression test for double eval on a single script element > [INFO] => Runs the double eval test > [INFO] ✔ double evaluation of embedded scripts testcase (281ms) > [INFO] > http://localhost:8080/IntegrationJSTest/integrationtestsjasmine/test11-scriptblocks.jsf > [INFO] Page test11-scriptblocks Successes: > [INFO] => Script blocks in various formats > [INFO] => Performs a script bloc test > ... > > [INFO] => Execute none handling > [INFO] => SPEC HAS NO EXPECTATIONS runs an execute request with execute > @none > [INFO] ✔ execute parameter test (281ms) > [INFO] > [INFO] > [INFO] 19 passing (23s) > [INFO] > [INFO] > [INFO] --- maven-failsafe-plugin:2.12:verify (default) @ IntegrationJSTest > --- > > This how it looks if all tests have passed > > or in case of a failure: > [INFO] 18 passing (23s) > [INFO] 1 failing > [INFO] > [INFO] 1) Integration Testsuite MyFaces > [INFO]testing viewRoot: > [INFO] > [INFO] AssertionError: expected false to be true > [INFO] + expected - actual > [INFO] > [INFO] -false > [INFO] +true > [INFO] > [INFO] at Context. > (src/main/webapp/resources/myfaces.testscripts/integrationtestrunner_frontend/integrationtests.spec.js:75:28) > [INFO] at processTicksAndRejections > (node:internal/process/task_queues:96:5) > [INFO] > [INFO] > [INFO] > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > > The config is as follows: > > The advantage is that the tests are now way easier to write and hook > themselves perfectly into the client side unit test system. > > Next advantage you also can run the tests directly in your browser and you > also can show a browser instead of an headless embedded chrome. > > We also would get 17-18 additional integration tests "for free" in the > myfaces codebase, simply because I have them already written a long time > ago. > The disadvantage is (whether this really is one) we bypass Aqulian in > favor of the frontend plugin node and mocha. > > I have this system working now, but as usual would perform another round > of cleanups before merging it into myfaces, after the RC3 jsf_ts merge. > So what´s your opinion, shall we add those tests to the codebase? I do not > have any problem, to leave them where they are, they work fine for my > purposes. > > > Werner > > >
