[3.33] Move quarkus-cxf-test-util-internal in camel-quarkus-integration-test-cxf-soap-grouped back to use correct property

[jedla97]

We (Quarkus QE) building custom platform for our testing. In last build we spotted failure when building platform for 3.33. In 9f12b59#diff-405d042550bf01fefb20a9c7759b93fa0c37ca2eddcc3fce410c6f2d410b30f7L33 it was changed to hard coded version (where I don't see that much problem) and in c17fb5c#diff-405d042550bf01fefb20a9c7759b93fa0c37ca2eddcc3fce410c6f2d410b30f7L33 it was changed again but to quarkus.version which should not be. When we building with custom Quarkus version it failing to build as it can't find the quarkus-cxf-test-util-internal with our custom Quarkus version (3.33.999-SNAPSHOT).

I don't know if if the change in from quarkus-cxf.version was for some specific reason or not so atm I proposing go back to quarkus-cxf.version

cc @ppalaga @jmartisk as you are the one which updated this

Edit when I run the ./mvnw -Dsync I see that this was overwritten back to quarkus.version

[quarkus-bot]

/cc @aloubyansky (3.33), @gsmet (3.33), @jmartisk (3.33), @rsvoboda (3.33)

[rsvoboda]

cc @ppalaga

[rsvoboda]

Main looks ok - https://github.com/quarkusio/quarkus-platform/blob/main/generated-platform-project/quarkus-camel/integration-tests/camel-quarkus-integration-test-cxf-soap-grouped/pom.xml#L33C1-L33C48

[aloubyansky]

This change won't have any effect, since the generated-platform-project is regenerated on every build and is not supposed to be modified by any other means.
If we launch the CI for this PR it will probably fail because the generated project will be different from the what is suggested.

This is long standing issue. Basically, you should pretty much ignore which properties are used for versions in the generated project, unless the actual values appear to be wrong.

Here is my guess why quarkus.version is used in this case.
That artifact is not managed in a BOM. So it has to have a specific version. When test modules are generated, dependencies that aren't managed keep their original versions - the versions in the original test module.

It looks like somehow the test artifact used for this test got unaligned with the rest of the CXF artifacts integrated in the platform, which is why you noticed a "hardcoded" 3.33.2 version first.
Then when Quarkus version changed to 3.33.2 in the platform, the Quarkus version matched that artifact's version and generator is trying to match dependency versions to existing version properties and that's how it picked up quarkus.version.

To fix this, the integrated test artifact (that's used for this test module generation) needs to be aligned with the rest of the CXF artifacts.
@ppalaga i guess, this one is for you.

[jmartisk]

Note: to get this fixed in the upcoming 3.33.2 platform release, I'd need a fix by tomorrow, @ppalaga

[aloubyansky]

A quick workaround could be to enforce the proper version of this artifact in the platform itself, I.e. by adding it to the cxf bom. I am not sure if there is more appropriate quick fix.

[jmartisk]

Given that

• I plan to start the 3.33.2 platform release tonight
• the proper fix would need a quarkus-cxf release
• QE seems to have a workaround
• it only concerns testing

I would probably defer the fix to 3.33.3

[ppalaga]

I have looked at the reported issue as much as I could and here is my take:

The fact that quarkus-cxf-test-util-internal is not managed in any of the end user facing BOMs is intentional.
It is there for our internal testing of our BOMs and extensions, rather than for customers and the testing of their apps.

I do not see anything Camel Quarkus or Quarkus CXF could do better.

The issue is that the BOM generator chooses ${quarkus.version} for quarkus-cxf-test-util-internal that is kinda "not incorrect" when looking at the given state of the platform repo alone, but is not right when @jedla97 tries to build with -Dquarkus.version=3.33.999-SNAPSHOT. BOM generator was simply not designed in a way that would always and reliably allow that.

I see two options to fix this:

A. The BOM generator stops choosing the wrong properties for the artifacts.

B. The QE team will regenerate the BOMs when building their custom platform - something like mvn -Dsync -Dquarkus.version=3.33.999-SNAPSHOT.

[aloubyansky]

It's the second option. Platform BOMs are flattened and do not include properties. So not regenerating them will not be equivalent to actually updating the Quarkus version in the platform.

[ppalaga]

@aloubyansky the issue we have is not with the generated BOMs, but with generated test modules. Those are generated by GeneratePlatformProjectMojo too. The flat version literal -> property backtracking in GeneratePlatformProjectMojo delivers wrong results. I think the option A is still valid.

[aloubyansky]

What would be the point of running tests with a Quarkus version that different from the generated BOMs though? Or am I misunderstanding the flow?

[aloubyansky]

A. The BOM generator stops choosing the wrong properties for the artifacts.

It'd be great to improve on that in any case, of course.