quarkus update updating version but not platform when switching registries

maxandersen commented 2 weeks ago

Describe the bug

I was testing out quarkus update ability to update between versions, i.e. from a io.quarkus to com.redhat.quarkus platform. And it seems that quarkus update blindly update the version without checking the platform name.

resulting in update failing as its just a partial update.

Expected behavior

we switch both version and platform:

<quarkus.platform.group-id>io.quarkus.platform<quarkus.platform.group-id>
<quarkus.platform.version>3.8.6</quarkus.platform.version>

to

<quarkus.platform.group-id>com.redhat.quarkus.platform<quarkus.platform.group-id>
<quarkus.platform.version>3.8.5.SP1-redhat-00001</quarkus.platform.version/>

or tell that user has to explicitly ask for platform switch.

Actual behavior

we get just platform version change,i.e.;

<quarkus.platform.version>3.8.6</quarkus.platform.version>

to

<quarkus.platform.version>3.8.5.SP1-redhat-00001</quarkus.platform.version/>

How to Reproduce?

run with default ~/.quarkus/config.yml content: quarkus create app -S=3.8 to get a io.quarkus version, could also be 3.7 - could also be higher but in this this case keep it at 3.8 as otherwise we bump into quarkus-rest rename that is separate concern.

then build that app and check it works. at time of writing it picked up 3.8.6

then go add redhat registry as the primary choice:

---
registries:
- registry.quarkus.redhat.com
- registry.quarkus.io

including adding https://maven.repository.redhat.com/ga/ to ~/.m2/settings.xml to be able to resolve dependencies.

Then run:

quarkus update -S=3.8

which at time of writing will pickup a 3.8.5-SP1-redhat-00001 and result in build failure because it only changes the platform version - NOT the platform group.

Output of `uname -a` or `ver`

No response

Output of `java -version`

No response

Quarkus version or git rev

No response

Build tool (ie. output of `mvnw --version` or `gradlew --version`)

No response

Additional information

furthermore, also tried quarkus update -P=com.redhat.quarkus.platform:3.8.5.SP1-redhat-00001 to help it but then also fails.

gsmet commented 2 weeks ago

I wouldn't say it's a bug but more something that it wasn't implemented.

I know we discussed it a few times, it's probably something that wouldn't be too hard to fix, given I think @aloubyansky already did all the hard work, it's just a matter of wiring things properly. I'll have a look soon.

aloubyansky commented 2 weeks ago

That should definitely work. The "instructions" logged should mention it. If it's not applied with recipes then it should be fixed.

maxandersen commented 2 weeks ago

@gsmet i'm 87% sure this worked in the past or at least we didn't change the version if platform was not requested. At least it was part of the very early things we aimed for. It might very well be it was lost at some point.

@aloubyansky which "instructions" are you thinking of ? I don't see some but happy to add flags and report/test ?

maxandersen commented 2 weeks ago

At least an explicit platform selection should work (quarkus update -P=com.redhat.quarkus.platform:3.8.5.SP1-redhat-00001), but I can't get that to work either.

maxandersen commented 2 weeks ago

@aloubyansky which "instructions" are you thinking of ? I don't see some but happy to add flags and report/test ?

found them! and yes, it seems recorded and then its like you said probably a case of the rewrite rule missing it:

Looking for the newly published extensions in registry.quarkus.io
[INFO] Detected project Java version: 21
[INFO] Detected project Java version: 21
[INFO] Instructions to update this project from '3.8.6' to '3.8.5.SP1-redhat-00001':
[INFO] Recommended Quarkus platform BOM updates:
[INFO] Add:    com.redhat.quarkus.platform:quarkus-bom:pom:3.8.5.SP1-redhat-00001
[INFO] Remove: io.quarkus.platform:quarkus-bom:pom:3.8.6
[INFO]
[INFO] Extensions from com.redhat.quarkus.platform:quarkus-bom:
[INFO]

gsmet commented 2 weeks ago

No it never worked. I think Thomas already reported it once.

gsmet commented 2 weeks ago

@aloubyansky so my understanding is that we should use ProjectPlatformUpdateInfo as the source of truth for this and adjust based on it?

There is no way to have some sort of mapping between the platforms there? Because ideally, I would like to update in place (when we can) as I'm not entirely sure OpenRewrite will add the new managed dependency at the right place if I don't. I'm not entirely sure if you have the info at your level that both platforms are similar? (I could match the artifactIds as an approximation but I'm not entirely sure it would be safe)

aloubyansky commented 2 weeks ago

At this point, technically, we don't have a notion of a "similar" replaceable platform BOM. We could come up with some logic around it, for example, we know which BOMs are recommended to be removed and which ones to be added (as the text-based version does). Then we can compare whether it's a groupId and version change, in which case we could try replacing those values.

gsmet commented 2 weeks ago

OK, will try to come up with something.

quarkusio / quarkus