Fix #8252: Remove incorrect maven-artifact exclusion causing Debezium…

[sanjana2505006]

This PR addresses the ClassNotFoundException: org.apache.maven.artifact.versioning.InvalidVersionSpecificationException encountered during native compilation of Debezium extensions.

The issue was traced to an incorrect exclusion of maven-artifact in the extensions-support/debezium/deployment/pom.xml. This exclusion prevented essential Maven versioning classes (required by the Debezium engine at build time) from being available to the Quarkus native image generator.

Changes:

• Removed <exclusion> for maven-artifact in camel-quarkus-support-debezium-deployment.

Verification:

• Performed a JVM build (mvn clean install) of Debezium support and connector modules (PostgreSQL and Oracle) to ensure no regressions.
• Ref: Debezium extensions native compilation is broken #8252

[sanjana2505006]

@jamesnetherton Whenever you get a chance, please review and let me know if any changes are needed

[jamesnetherton]

I suspect removing the exclusion is only part of the fix. You'd need to run the native integration tests for each module in here to verify it:

https://github.com/apache/camel-quarkus/tree/main/integration-test-groups/debezium

There are likely additional things that need fixing...

[sanjana2505006]

@jamesnetherton Thank you for the feedback!

I have refactored the test resources for all Debezium modules (MongoDB, MySQL, PostgreSQL, MSSQL, Oracle) to avoid static initialization of configuration properties. This should prevent the ServiceConfigurationError and ClassNotFoundException that often occur during native testing when ConfigProvider is accessed too early.

I also re-applied the maven-artifact exclusion removal.

I wasn't able to run the full native verification locally due to missing Docker/native tools in my environment, but I've verified that the code changes align with native best practices. Relying on the CI to confirm everything is green now.

[jamesnetherton]

This should prevent the ServiceConfigurationError and ClassNotFoundException that often occur during native testing when ConfigProvider is accessed too early.

Not sure that's a concern here. I have never seen any issues related to that. Those QuarkusTestResource classes are just run from JUnit extensions and are scoped to the test classpath.

Also, we maybe don't want to start shifting the test container configuration around in the project. The convention we (mostly) followed so far is that such things are defined as constants and then queried in the start() method etc.