Open turing85 opened 1 year ago
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.
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:
Thanks @middagj, added it to the list above.
Here's another idea (not 100% sure if this will work):
test-jar
(see the corresponding maven.apache.org
documentation, this must be done on the owner-side)This would entail:
test-jar
as artifact to maven-test.jar
of the owner as dependency or parent@middagj @zhfeng do you think that this could work?
@turing85 I think it could work. But I'm not sure how to override in client-side?
@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.
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:
main
-branch ofcamel-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.camel-jms
, but we could additionally add tests forcamel-sjms
andcamel-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.
camel-quarkus
orquarkus-artemis
?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)