Re: Added Support for JUnit 5
This is amazing!
> On Oct 12, 2021, at 3:37 PM, Dale Emery wrote:
>
> In September 2021, Geode added support for writing and running tests using
> JUnit 5.
>
> Most Geode modules now support JUnit 5. For most Geode modules, you can now
> write each test class using either JUnit 5's "Jupiter" API or the legacy
> JUnit 4 API.
>
> Which modules support JUnit 5? Any source set that depends on geode-junit or
> geode-dunit already has JUnit 5 support. For those source sets you can start
> writing tests using the JUnit Jupiter API now, and Gradle will run them.
>
> To add JUnit 5 support to a module or source set: Add lines like these to the
> "dependencies" configuration of the module’s build.gradle file:
>
>
> testImplementation('org.junit.jupiter:junit-jupiter-api')
>
> testRuntimeOnly('org.junit.jupiter:junit-jupiter-engine')
>
> The first line allows you to write unit tests using the JUnit Jupiter API.
> The second line allows Gradle to run your JUnit Jupiter unit tests.
>
> To use JUnit Jupiter to write and run other kinds of tests (e.g.
> integrationTest or distributedTest), add similar lines to configure the
> appropriate source sets.
>
> LIMITATIONS
>
> * Because Geode support for JUnit Jupiter is so new, we have not yet added
> test framework code that takes advantage of its features.
> * JUnit Jupiter does not support the use of Rules.
>
> SEE ALSO
>
> * The JUnit 5 User Guide:
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjunit.org%2Fjunit5%2Fdocs%2Fcurrent%2Fuser-guide%2Fdata=04%7C01%7Cjabarrett%40vmware.com%7C736b38c71e7a427f0c2c08d98dd0ef35%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637696750780087368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=mT8Xx10xI1KL8p7kgvpc3VMkTvxjJDPZUz1z%2F4EcaRQ%3Dreserved=0
> * Using JUnit 5 (a copy of this message on the Geode wiki):
> https://cwiki.apache.org/confluence/display/GEODE/Using+JUnit+5
>
> Dale Emery
>
Added Support for JUnit 5
In September 2021, Geode added support for writing and running tests using
JUnit 5.
Most Geode modules now support JUnit 5. For most Geode modules, you can now
write each test class using either JUnit 5's "Jupiter" API or the legacy JUnit
4 API.
Which modules support JUnit 5? Any source set that depends on geode-junit or
geode-dunit already has JUnit 5 support. For those source sets you can start
writing tests using the JUnit Jupiter API now, and Gradle will run them.
To add JUnit 5 support to a module or source set: Add lines like these to the
"dependencies" configuration of the module’s build.gradle file:
testImplementation('org.junit.jupiter:junit-jupiter-api')
testRuntimeOnly('org.junit.jupiter:junit-jupiter-engine')
The first line allows you to write unit tests using the JUnit Jupiter API. The
second line allows Gradle to run your JUnit Jupiter unit tests.
To use JUnit Jupiter to write and run other kinds of tests (e.g.
integrationTest or distributedTest), add similar lines to configure the
appropriate source sets.
LIMITATIONS
* Because Geode support for JUnit Jupiter is so new, we have not yet added
test framework code that takes advantage of its features.
* JUnit Jupiter does not support the use of Rules.
SEE ALSO
* The JUnit 5 User Guide: https://junit.org/junit5/docs/current/user-guide/
* Using JUnit 5 (a copy of this message on the Geode wiki):
https://cwiki.apache.org/confluence/display/GEODE/Using+JUnit+5
Dale Emery
Re: Geode-9621: Spotless overstepping its boundary of formatter
I would not call it a “surge” of them, but I perceived an uptick in them. From: Udo Kohlmeyer Date: Tuesday, October 12, 2021 at 1:00 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter I had never explicitly asked this, but what was the main driver for this ticket? Was there a surge in explicit version definitions in gradle files? I mean we as committers have agreed to using BOM constraints. --Udo From: Robert Houghton Date: Wednesday, October 13, 2021 at 4:32 AM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Again, Spotless is not changing code. That was a bad change, as you pointed out, and we modified Spotless to throw an exception instead of stripping out the version string indiscriminately. We surely could make Spotless only apply to the main source set. The cost would be that tests could use different versions than production. That tests could themselves specify multiple versions at once, and that tests would be out-of-sync with each other, and with the production code. So I would strongly vote against that. -Robert From: Udo Kohlmeyer Date: Monday, October 11, 2021 at 5:32 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test with, into the `DependencyConstraints` file just feels like the wrong approach. The prior art you refer to, is a specific version of tomcat we want each module to use. It is no different to specifying the exact artifact version we want for production code. My case is that I don’t want my artifact version dependencies to leak outside of the test module. I think, the fact that the decision to elevate spotless from cosmetic formatter to actually having a significant impact, was done unilaterally. Please don’t get me wrong, I love the fact that we want to fix the problem where developers are not following good practices. But I think I am digging in here, because I believe we missed an opportunity to get more voices in this decision. I also firmly believe that spotless is overstepping the “cosmetic” boundary. I think many developers would feel upset if their code were to be changed. If spotless suddenly replaces a for-loop with a stream implementation. I think it is one thing to decide if gradle should be formatted with 2 spaces vs 4, or when and how lines wrap, and it’s another for spotless to just remove version information and force one consistent version even if the version was specifically overriden. I wonder if we can maybe reduce the area of effect of this change and really only force the version formatter to activate for the ‘main’ configuration and leave every other configuration type (test, distributedTest, integrationTest, acceptanceTest, upgradeTest) alone. --Udo From: Robert Houghton Date: Tuesday, October 12, 2021 at 10:38 AM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Currently there is no way to exclude certain code blocks from the malicious code formatter. Therefore, my tests that require a specific hardcoded version of Spring to be used, will always either fail the validation or tests will fail due to spotless changing my testing scenario by affecting the version of the library that we have to use. Udo, I have worked with you to accomplish your goal of not automatically “fixing” the inclusion of dependency versions in the build files, as your work case wants to do something special there. The formatter now throws when there is a naked version-string on the dependency line, as we discussed. If you want to continue to work around this, there are many cases of prior art in Geode, such as extensions/geode-modules-tomcat9/build.gradle, where specific versions are allowed. Good luck. -Robert Houghton
Re: Geode-9621: Spotless overstepping its boundary of formatter
I had never explicitly asked this, but what was the main driver for this ticket? Was there a surge in explicit version definitions in gradle files? I mean we as committers have agreed to using BOM constraints. --Udo From: Robert Houghton Date: Wednesday, October 13, 2021 at 4:32 AM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Again, Spotless is not changing code. That was a bad change, as you pointed out, and we modified Spotless to throw an exception instead of stripping out the version string indiscriminately. We surely could make Spotless only apply to the main source set. The cost would be that tests could use different versions than production. That tests could themselves specify multiple versions at once, and that tests would be out-of-sync with each other, and with the production code. So I would strongly vote against that. -Robert From: Udo Kohlmeyer Date: Monday, October 11, 2021 at 5:32 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test with, into the `DependencyConstraints` file just feels like the wrong approach. The prior art you refer to, is a specific version of tomcat we want each module to use. It is no different to specifying the exact artifact version we want for production code. My case is that I don’t want my artifact version dependencies to leak outside of the test module. I think, the fact that the decision to elevate spotless from cosmetic formatter to actually having a significant impact, was done unilaterally. Please don’t get me wrong, I love the fact that we want to fix the problem where developers are not following good practices. But I think I am digging in here, because I believe we missed an opportunity to get more voices in this decision. I also firmly believe that spotless is overstepping the “cosmetic” boundary. I think many developers would feel upset if their code were to be changed. If spotless suddenly replaces a for-loop with a stream implementation. I think it is one thing to decide if gradle should be formatted with 2 spaces vs 4, or when and how lines wrap, and it’s another for spotless to just remove version information and force one consistent version even if the version was specifically overriden. I wonder if we can maybe reduce the area of effect of this change and really only force the version formatter to activate for the ‘main’ configuration and leave every other configuration type (test, distributedTest, integrationTest, acceptanceTest, upgradeTest) alone. --Udo From: Robert Houghton Date: Tuesday, October 12, 2021 at 10:38 AM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Currently there is no way to exclude certain code blocks from the malicious code formatter. Therefore, my tests that require a specific hardcoded version of Spring to be used, will always either fail the validation or tests will fail due to spotless changing my testing scenario by affecting the version of the library that we have to use. Udo, I have worked with you to accomplish your goal of not automatically “fixing” the inclusion of dependency versions in the build files, as your work case wants to do something special there. The formatter now throws when there is a naked version-string on the dependency line, as we discussed. If you want to continue to work around this, there are many cases of prior art in Geode, such as extensions/geode-modules-tomcat9/build.gradle, where specific versions are allowed. Good luck. -Robert Houghton
Re: Geode-9621: Spotless overstepping its boundary of formatter
Again, Spotless is not changing code. That was a bad change, as you pointed out, and we modified Spotless to throw an exception instead of stripping out the version string indiscriminately. We surely could make Spotless only apply to the main source set. The cost would be that tests could use different versions than production. That tests could themselves specify multiple versions at once, and that tests would be out-of-sync with each other, and with the production code. So I would strongly vote against that. -Robert From: Udo Kohlmeyer Date: Monday, October 11, 2021 at 5:32 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test with, into the `DependencyConstraints` file just feels like the wrong approach. The prior art you refer to, is a specific version of tomcat we want each module to use. It is no different to specifying the exact artifact version we want for production code. My case is that I don’t want my artifact version dependencies to leak outside of the test module. I think, the fact that the decision to elevate spotless from cosmetic formatter to actually having a significant impact, was done unilaterally. Please don’t get me wrong, I love the fact that we want to fix the problem where developers are not following good practices. But I think I am digging in here, because I believe we missed an opportunity to get more voices in this decision. I also firmly believe that spotless is overstepping the “cosmetic” boundary. I think many developers would feel upset if their code were to be changed. If spotless suddenly replaces a for-loop with a stream implementation. I think it is one thing to decide if gradle should be formatted with 2 spaces vs 4, or when and how lines wrap, and it’s another for spotless to just remove version information and force one consistent version even if the version was specifically overriden. I wonder if we can maybe reduce the area of effect of this change and really only force the version formatter to activate for the ‘main’ configuration and leave every other configuration type (test, distributedTest, integrationTest, acceptanceTest, upgradeTest) alone. --Udo From: Robert Houghton Date: Tuesday, October 12, 2021 at 10:38 AM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Currently there is no way to exclude certain code blocks from the malicious code formatter. Therefore, my tests that require a specific hardcoded version of Spring to be used, will always either fail the validation or tests will fail due to spotless changing my testing scenario by affecting the version of the library that we have to use. Udo, I have worked with you to accomplish your goal of not automatically “fixing” the inclusion of dependency versions in the build files, as your work case wants to do something special there. The formatter now throws when there is a naked version-string on the dependency line, as we discussed. If you want to continue to work around this, there are many cases of prior art in Geode, such as extensions/geode-modules-tomcat9/build.gradle, where specific versions are allowed. Good luck. -Robert Houghton
Re: Region is not created on one of the servers
I think maybe a better option might be to use a lock for the cluster configuration. We can make the request to get the cluster config wait until the update to the cluster config is completely applied. Maybe we already have a lock to force cluster configuration updates to happen one at a time? -Dan From: Mario Kevo Sent: Tuesday, October 12, 2021 1:35 AM To: dev@geode.apache.org Subject: Odg: Region is not created on one of the servers The new ticket is opened. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FGEODE-9718data=04%7C01%7Cdasmith%40vmware.com%7C712ca6480e4642cb8dd108d98d5b3ac0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637696245240683976%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Q4suASyMhog5N8ZWdBH266udGFxe9MBQVMKEkms1zhM%3Dreserved=0 There are two proposals on the ticket, so it should be decided in which way we should go. BR, Mario Šalje: Udo Kohlmeyer Poslano: 12. listopada 2021. 0:59 Prima: dev@geode.apache.org Predmet: Re: Region is not created on one of the servers Hi Mario, I think your assessment of the problem is correct. Thinking about it, there is no simple (correct) way to easily solve this. Given that there are too many variables in play, users making configurational changes, whilst servers are coming up. Now, that said, I think we should address this problem. I also think your assessment is correct that cluster configuration was not written to handle this scenario. I think some thought has to go into the algorithm that one would like to follow and how we would like to resolve it. Can you please raise a ticket on this issue. --Udo From: Mario Kevo Date: Monday, October 11, 2021 at 11:27 PM To: dev@geode.apache.org Subject: Odg: Region is not created on one of the servers I think that there can be a problem if we change to first add it to cluster config and then do distribution to existing servers. Now, when the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this can happen for all commands that editing cluster configuration. It looks like this is not designed to execute some commands in parallel with starting servers. BR, Mario Šalje: Dan Smith Poslano: 8. listopada 2021. 20:37 Prima: dev@geode.apache.org Predmet: Re: Region is not created on one of the servers This seems like something ought to work, so I would call it a bug if the region didn't get created on 1 server. At first glance, it looks like the problem is that we distribute the region to all the servers before adding it to cluster config? Seems like we need to do distribution after adding the region to cluster config, to make sure that all servers get the region. -Dan From: Mario Kevo Sent: Friday, October 8, 2021 5:31 AM To: dev@geode.apache.org Subject: Region is not created on one of the servers Hi geode-dev, We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. There is an example of the problem: We started the locator, and then go with starting the servers, one by one. In the meantime, we run the "create region" command through gfsh. All servers that are started before the "create region" command got information to create a region on itself, but the problem is in the server which is started after the "create region" command is started and not finished yet. After the "create region" command is finished, all other servers started after that will get that region in the cluster configuration and create it. What happened with this one server without a region? It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So the question is, is it allowed to run commands in parallel? If yes, we should do some checks in the code to avoid this issue. If not, we need to write it somewhere in the documentation. BR, Mario
Re: Geode-9621: Spotless overstepping its boundary of formatter
>The formatter now throws when there is a naked version-string on the >dependency line, as we discussed. This new behavior seems reasonable to me. And I think this is what you are asking for, Udo? I do agree that spotlessApply shouldn't change any behavior and cause someone to lose part of their changes as a result. -Dan From: Udo Kohlmeyer Sent: Monday, October 11, 2021 5:32 PM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Hi there Robert, Yes, you did work with me, but the solution to add my custom versions of jars that I want to test with, into the `DependencyConstraints` file just feels like the wrong approach. The prior art you refer to, is a specific version of tomcat we want each module to use. It is no different to specifying the exact artifact version we want for production code. My case is that I don’t want my artifact version dependencies to leak outside of the test module. I think, the fact that the decision to elevate spotless from cosmetic formatter to actually having a significant impact, was done unilaterally. Please don’t get me wrong, I love the fact that we want to fix the problem where developers are not following good practices. But I think I am digging in here, because I believe we missed an opportunity to get more voices in this decision. I also firmly believe that spotless is overstepping the “cosmetic” boundary. I think many developers would feel upset if their code were to be changed. If spotless suddenly replaces a for-loop with a stream implementation. I think it is one thing to decide if gradle should be formatted with 2 spaces vs 4, or when and how lines wrap, and it’s another for spotless to just remove version information and force one consistent version even if the version was specifically overriden. I wonder if we can maybe reduce the area of effect of this change and really only force the version formatter to activate for the ‘main’ configuration and leave every other configuration type (test, distributedTest, integrationTest, acceptanceTest, upgradeTest) alone. --Udo From: Robert Houghton Date: Tuesday, October 12, 2021 at 10:38 AM To: dev@geode.apache.org Subject: Re: Geode-9621: Spotless overstepping its boundary of formatter Currently there is no way to exclude certain code blocks from the malicious code formatter. Therefore, my tests that require a specific hardcoded version of Spring to be used, will always either fail the validation or tests will fail due to spotless changing my testing scenario by affecting the version of the library that we have to use. Udo, I have worked with you to accomplish your goal of not automatically “fixing” the inclusion of dependency versions in the build files, as your work case wants to do something special there. The formatter now throws when there is a naked version-string on the dependency line, as we discussed. If you want to continue to work around this, there are many cases of prior art in Geode, such as extensions/geode-modules-tomcat9/build.gradle, where specific versions are allowed. Good luck. -Robert Houghton
Odg: Region is not created on one of the servers
The new ticket is opened. https://issues.apache.org/jira/browse/GEODE-9718 There are two proposals on the ticket, so it should be decided in which way we should go. BR, Mario Šalje: Udo Kohlmeyer Poslano: 12. listopada 2021. 0:59 Prima: dev@geode.apache.org Predmet: Re: Region is not created on one of the servers Hi Mario, I think your assessment of the problem is correct. Thinking about it, there is no simple (correct) way to easily solve this. Given that there are too many variables in play, users making configurational changes, whilst servers are coming up. Now, that said, I think we should address this problem. I also think your assessment is correct that cluster configuration was not written to handle this scenario. I think some thought has to go into the algorithm that one would like to follow and how we would like to resolve it. Can you please raise a ticket on this issue. --Udo From: Mario Kevo Date: Monday, October 11, 2021 at 11:27 PM To: dev@geode.apache.org Subject: Odg: Region is not created on one of the servers I think that there can be a problem if we change to first add it to cluster config and then do distribution to existing servers. Now, when the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this can happen for all commands that editing cluster configuration. It looks like this is not designed to execute some commands in parallel with starting servers. BR, Mario Šalje: Dan Smith Poslano: 8. listopada 2021. 20:37 Prima: dev@geode.apache.org Predmet: Re: Region is not created on one of the servers This seems like something ought to work, so I would call it a bug if the region didn't get created on 1 server. At first glance, it looks like the problem is that we distribute the region to all the servers before adding it to cluster config? Seems like we need to do distribution after adding the region to cluster config, to make sure that all servers get the region. -Dan From: Mario Kevo Sent: Friday, October 8, 2021 5:31 AM To: dev@geode.apache.org Subject: Region is not created on one of the servers Hi geode-dev, We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. There is an example of the problem: We started the locator, and then go with starting the servers, one by one. In the meantime, we run the "create region" command through gfsh. All servers that are started before the "create region" command got information to create a region on itself, but the problem is in the server which is started after the "create region" command is started and not finished yet. After the "create region" command is finished, all other servers started after that will get that region in the cluster configuration and create it. What happened with this one server without a region? It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So the question is, is it allowed to run commands in parallel? If yes, we should do some checks in the code to avoid this issue. If not, we need to write it somewhere in the documentation. BR, Mario
