Add camel-based artemis-jms tests to camel-quarkus

[turing85]

We have some integration test to test integration with camel-quarkus. To detect integration problems early, we would like to also add them to the camel-quarkus-project.

Considerations:

• The main-branch of camel-quarkus is currently in migration to Quarkus 3. There is no alpha-release based on Quarkus 3 yet, so migrating the tests now might be challenging since we cannot build a version based on Quarkus 3 with the camel integration features.
• Our integration tests use "only" camel-jms, but we could additionally add tests for camel-sjms and camel-sjms2.

Discussion:

• We should avoid code duplication as much as possible. This means we want one project to "own" the tests, and another project to use them.
  • Who should "own" the tests? camel-quarkus or quarkus-artemis?
  • There are several approaches to avoid code duplication. Some are:
    • Integrate the tests from the owner to the user via a git submodule.

      • Upside: easy to implement.
      • Downsides:
        • Submodules are tricky, they have to be manaully updated (since they always target specific commits)
        • The user will have a hard time to override dependency versions
        • The pipeline has to be modified.
    • Integrate by "mirroring" the test modules from the owner in the user.

      • Rough sketch on how to do this:
        • For each test module from the owner, create a corresponding test module.
        • In the module, create a corresponding class for each Test-class, extend the owner's test class. If necessary, add additional test methods (but this really should not be necessary).
      • Upsides:
        • Client has maximum flexibility.
        • This will "just work" with the current pipeline.
      • Downsides:
        • initial setup is more complex.
        • If the owner adds a new test class, this should also be added to the user, to keep them "in sync".
    • Bundle the tests in a specific package in camel and define a small copy script here and just sync now and then by committing changes.

      • Upsides:
        • No third library to maintain with all the plumbing
        • Clear ownership
        • New tests get automatically copied
        • It will work with current pipeline without any changes
      • Downsides:
        • Customization in one library is difficult (or even not possible)
        • Easy to get the sync broken, since it is just a process
        • Changes from the copier need to be merged into the source via a PR first for breaking changes (one could also say that is a benefit)

[turing85]

since quarkus-artemis provides the implementation used by quarkus-camel, I tend to say that quarkus-artemis should be the owner, and quarkus-camel the user.

With regards to the ingeration options, I favor the 2nd approach. While submodules are a quick win, it is too limiting and introduces too much maintenance overhead and friction.

[middagj]

I think the owner should be Camel, as they are using Artemis as a dependency and are probably best in to come up with the broadest test. But I can also see the other way and the reasoning.

As for the approaches, I favor the second approach as well. I would even be fine with an even simpler approach:

• Approach 3: Bundle the tests in a specific package in camel and define a small copy script here and just sync now and then by committing changes.
  • Upsides
    • No third library to maintain with all the plumbing
    • Clear ownership
    • New tests get automatically copied
    • It will work with current pipeline without any changes
  • Downsides:
    • Customization in one library is difficult (or even not possible)
    • Easy to get the sync broken, since it is just a process
    • Changes from the copier need to be merged into the source via a PR first for breaking changes (one could also say that is a benefit)

[turing85]

Thanks @middagj, added it to the list above.

[turing85]

Here's another idea (not 100% sure if this will work):

• package all tests into a test-jar (see the corresponding maven.apache.org documentation, this must be done on the owner-side)
• Import these tests along with the non-test dependencies on the client-side. The module on the client-side can otherwise be completely empty. If my theory holds, the test should "just be executed". And the client should be able to override, for example, versions.

This would entail:

• A small POC to see whether this all works as expected
• If it does:
  • minor changes to the module on the owner's side to expose the test-jar as artifact to maven
  • a test-module on the client-side, that has the -test.jar of the owner as dependency or parent

@middagj @zhfeng do you think that this could work?

[zhfeng]

@turing85 I think it could work. But I'm not sure how to override in client-side?

[turing85]

@turing85 I think it could work. But I'm not sure how to override in client-side?

@zhfeng The versions should be overridable; the tests themselves are not modifiable. We can - of course - add additional tests. This would pretty much follow the open-close principle (en.wikipedia.org):

Be open for extension, but closed for modification.

A benefit would be that this ensures that camel and quarkus-artemis use the same exact tests.