Fix #476 List itests in an XML file for the Quarkus platform

[ppalaga]

There is no version in the XML list of tests anymore as proposed by @lburgazzoli.
The XML is now deployed directly instead of being deployed in a jar.

[lburgazzoli]

wonder if as future evolution, the xml with the list of the integration-test could be auto generated like all the it with a specific property are included (or excluded)

[ppalaga]

bd419b9 fixes the license header problem

[ppalaga]

be auto generated like all the it with a specific property are included (or excluded)

(Not sure you noticed) it is currently autogenerated and there is some file path based filtering there. Is that not enough? https://github.com/apache/camel-quarkus/pull/482/files#diff-e0dff2635520bef5f237973025e0a295R51-R63

[lburgazzoli]

oh, damn me. didn't notice

[lburgazzoli]

got confused because I saw the generated file also included in the repo, maybe as it is auto generated it should not be checked in

[ppalaga]

auto generated it should not be checked in

I prefer to have it in git to be able to check anytime quickly what we export and also to have the history thereof. WDYT?

Now fixing the JAXB issue on Java 11.

[lburgazzoli]

in general I'd go for not including auto generated code as It may be another source of conflicts and confusion as people may try to change them manually but it is not a huge issue

[ppalaga]

Yes, potential merge conflicts in the XML file would be nice to avoid.

The main motivation for me to keep the file in Git for now is that we have some irregularities in the integration-tests directory and the selection done by the plugin may get broken in the future. Having a chance to spot malign changes during the PR review could prevent that. - That's actually a sign that we should try to find a mechanism for exporting the tests that would be more robust than the current path matching. I vote for merging this PR as is and continue the discussion withing #413 . Either the selection could work based on properties in the test POMs (the irregularities in main an core are still there) as you proposed or maybe we could put the aggregated tests into a new directory where we'd keep a strictly flat layout (so that the path matching would be less likely to break).

[lburgazzoli]

ok to test

[lburgazzoli]

@ppalaga I have no objection to keep it now but long term solution would be better to remove it.

We may think to move support test extension in a dedicated support folder so main and core and future it tests are just like other tests and we only need to skip indexing the support folder

[ppalaga]

move support test extension in a dedicated support folder so main and core and future it tests are just like other tests

What an elegant option!

[asf-ci]

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/camel-quarkus-pr/439/