anchor.diff:  Test using text block in Idea IDE.
   ====
   
  -You can manually set Java level to 17, but in this case you may unintentionally use Java > 11 features in non-test code without IDE letting you know.
  -Moreover, e.g. Idea reset the code level upon any changes in the `pom.xml` files.
  +You can manually set Java level to 17, but in this case you may unintentionally use Java > 11 features in non-test code without the IDE letting you know.
  +Moreover, e.g. Idea resets the code level upon any changes in the `pom.xml` files.
   Have you solved this issue?
   Or do you use an IDE which doesn't have issues with mixing different Java levels?
   Please share your experience in the discussion!
  
positive.code: }
  ----
  
  Once we solved the issue with Cassandra tests, we were mostly done and were ready to use Java 11/17.
  
  == Open issues
  
  We need more battle testing to be sure that everything works well with Java 11/17.
  Your help with testing and bug reports would be very valuable here and more than welcome.
  Currently we are aware of one minor unsolved issue related to the Java update.
  Some IDEs cannot distinguish between `maven.compiler.release` and `maven.compiler.testRelease` (or it's not very clear to us who to set it up).
  For example this test using https://openjdk.java.net/jeps/378[text block] is marked as an error in the IDE:
  
  [.centered-image.responsive-image]
  
negative.code: * https://www.testcontainers.org/[Testcontainers]
  
  We use the Fabric8 plugin in the rest of the project, which suggests to use it also in this case to have uniformity across the project.
  On the other hand, using Testcontainers would make tests more convenient for the developers (who actually use tests after all!),
  as it allows to run the tests directly from IDE without starting the container manually.
  In the end, the decision was driven by the fact that running a cleanup container is not possible with the Fabric8 plugin.
  Maven doesn't allow to execute different configurations in the same phase 
  and therefore it's not possible to stop the Cassandra container in the `post-integration-test` phase and at the same time run a cleanup container in this phase.
  Testcontainers allow starting and stopping containers programmatically when needed, 
  letting us define the images directly in the test code so we don't need any additional `Dockerfile`
  , and cleaning up the container is just an implementation detail hidden in the test itself.
  Having the ability to run the tests directly from an IDE, without having to manually start and stop a container with the database, is a nice benefit on top of these things.
  
  The only tricky thing when using Testcontainers was that when we tried to remove the log files using Docker's `cmd` command,
  Testcontainers randomly failed, stating that the container didn't start in spite of the fact that all Cassandra files were actually deleted.
  The container probably ran so fast that it finished before Testcontainers noticed it.
  Finally, we solved it by adding a short `sleep` in the container and executing an additional command in the container which does the cleanup.
  
  The final cleanup code using Testcontainers looks like this:
  
  [source, xml]
  ----
  