Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
turing85 opened this issue Feb 12, 2023 · 6 comments
Open

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

turing85 opened this issue Feb 12, 2023 · 6 comments

Comments

@turing85
Copy link
Contributor

turing85 commented Feb 12, 2023

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
Copy link
Contributor Author

turing85 commented Feb 12, 2023

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
Copy link
Contributor

middagj commented Feb 12, 2023

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
Copy link
Contributor Author

turing85 commented Feb 12, 2023

Thanks @middagj, added it to the list above.

@turing85
Copy link
Contributor Author

turing85 commented Mar 8, 2023

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
Copy link
Contributor

zhfeng commented Mar 8, 2023

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

@turing85
Copy link
Contributor Author

turing85 commented Mar 8, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants