Greatly improve Quarkus update

[ia3andy]

• Allow to run update even if only Quarkiverse extensions needs updates.
• Improve and fix info and update logs
• Add colors
• Fix recipe resolver algorithm
• Make update interactive by default (but add options -y/-n/-N)
• Fix issue when drop version specific version with Maven (to managed)
• Move rewrite logs in a log file (target/rewrite/rewrite.log) to have a clean update logging output
• Print patch file location in dry-run

update

info:

help:

Rewrite (interactive by default):
      --quarkus-update-recipes=<quarkusUpdateRecipes>
                           Use custom io.quarkus:quarkus-update-recipes:LATEST
                             artifact (GAV) or just provide the version. This
                             artifact should contain the base Quarkus update
                             recipes to update a project.
      --rewrite-plugin-version=<pluginVersion>
                           Use a custom OpenRewrite plugin version.
      --additional-update-recipes=<additionalUpdateRecipes>
                           Specify a list of additional artifacts (GAV)
                             containing rewrite recipes.
  -y, --yes                Run the suggested update recipe for this project.
  -N, --no, --no-rewrite   Do NOT run the update.
  -n, --dry-run            Do a dry run of the suggested update recipe for this
                             project.

Created #46460 for follow up work

[ia3andy]

@jtama that should fix the issue you told me on Zulip, could you give it a try

[jtama]

Works like a charm.

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 260cc85.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ JVM Integration Tests - JDK 21

📦 integration-tests/hibernate-orm-panache

✖ io.quarkus.it.panache.defaultpu.PanacheFunctionalityTest.testBug7102 - History

• expected: <jozo> but was: <pero> - org.opentest4j.AssertionFailedError

org.opentest4j.AssertionFailedError: expected: <jozo> but was: <pero>
	at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
	at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
	at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182)
	at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177)
	at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1145)
	at io.quarkus.it.panache.defaultpu.PanacheFunctionalityTest.testBug7102(PanacheFunctionalityTest.java:220)

✖ io.quarkus.it.panache.defaultpu.PanacheFunctionalityTest.testPanacheFunctionality - History

• 1 expectation failed. Response body doesn't match expectation. Expected: is "OK" Actual: {"details":"Error id eb08e8a9-1b26-471a-9b13-213f1c95d2a7-1, org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <1> but was: <0>","stack":"org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <1> but was: <0>\n\tat org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:107)\n\tat org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:344)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:205)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:452)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$invokePropagateNotFound$6(SynchronousDispatcher.java:275)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:154)\n\tat org.jboss.res... - java.lang.AssertionError

java.lang.AssertionError: 
1 expectation failed.
Response body doesn't match expectation.
Expected: is "OK"
  Actual: {"details":"Error id eb08e8a9-1b26-471a-9b13-213f1c95d2a7-1, org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <1> but was: <0>","stack":"org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <1> but was: <0>\n\tat org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:107)\n\tat org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:344)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:205)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:452)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$invokePropagateNotFound$6(SynchronousDispatcher.java:275)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.ja...

• 1 expectation failed. Response body doesn't match expectation. Expected: is "OK" Actual: {"details":"Error id a54215ae-c9e4-4792-9a92-7e89d35dfac7-1, org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <0> but was: <1>","stack":"org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <0> but was: <1>\n\tat org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:107)\n\tat org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:344)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:205)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:452)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$invokePropagateNotFound$6(SynchronousDispatcher.java:275)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:154)\n\tat org.jboss.res... - java.lang.AssertionError

java.lang.AssertionError: 
1 expectation failed.
Response body doesn't match expectation.
Expected: is "OK"
  Actual: {"details":"Error id a54215ae-c9e4-4792-9a92-7e89d35dfac7-1, org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <0> but was: <1>","stack":"org.jboss.resteasy.spi.UnhandledException: org.opentest4j.AssertionFailedError: expected: <0> but was: <1>\n\tat org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:107)\n\tat org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:344)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:205)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:452)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$invokePropagateNotFound$6(SynchronousDispatcher.java:275)\n\tat org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.ja...

[aloubyansky]

@gsmet you've contributed significantly to the update tooling, so I'd like you to be aware of this change and my perspective.

Generally, I don't have any substantial remarks about this change. Here is what I can say though.

1. This change removes the per-module option (but not the code handling it). The per-module option was supposed to be logging discovered Quarkus info per module in a multi module project (even if a module isn't an application but configured some Quarkus-related dependencies). I don't think it's a big deal, since I don't think this option was very popular any way and I think it would require more work to make it truly useful.

2. This change makes the info command behave as info --rectify originally did, i.e. what used to be rectify is now the default behavior. This option was checking for version alignment with the currently imported platform BOMs and Quarkus core version. It is kind of an update but not really checking for newer versions of the platforms or Quarkus core. It's meant more as a "fix" the project config rather than check for available updates.
   While I don't object here, I am not sure this is how we will want to keep it longer term. Before this change info would simply display what was discovered, w/o suggesting updates. It's less verbose and potentially less "expensive", since for non-platform extensions, rectify implies requesting information from the registry. It happens to be the case either way before this change but I am not sure we'll want to keep it in the future. But I won't object merging this.

The current implementation hasn't evolved much in terms of interface and presentation and I'd generally welcome this change but I also think we may re-think it later. I've been looking into a different "info reading" mechanism in the last couple of weeks, so I've been having some thoughts about this topic.

[ia3andy]

@gsmet you've contributed significantly to the update tooling, so I'd like you to be aware of this change and my perspective.

Generally, I don't have any substantial remarks about this change. Here is what I can say though.

1. This change removes the per-module option (but not the code handling it). The per-module option was supposed to be logging discovered Quarkus info per module in a multi module project (even if a module isn't an application but configured some Quarkus-related dependencies). I don't think it's a big deal, since I don't think this option was very popular any way and I think it would require more work to make it truly useful.

We still have the per-module in the info, the one in the update wasn't used.

2. This change makes the info command behave as info --rectify originally did, i.e. what used to be rectify is now the default behavior. This option was checking for version alignment with the currently imported platform BOMs and Quarkus core version. It is kind of an update but not really checking for newer versions of the platforms or Quarkus core. It's meant more as a "fix" the project config rather than check for available updates.
   While I don't object here, I am not sure this is how we will want to keep it longer term. Before this change info would simply display what was discovered, w/o suggesting updates. It's less verbose and potentially less "expensive", since for non-platform extensions, rectify implies requesting information from the registry. It happens to be the case either way before this change but I am not sure we'll want to keep it in the future. But I won't object merging this.

FYI we were doing the job of rectify to show some icons depending on the status. So it was a state in between just the current state and the rectify which wasn't really useful because you had to run another command to actually get the align info.

Also I created an issue for this as we discussed a few days ago: "Created #46460 for follow up work"

The current implementation hasn't evolved much in terms of interface and presentation and I'd generally welcome this change but I also think we may re-think it later. I've been looking into a different "info reading" mechanism in the last couple of weeks, so I've been having some thoughts about this topic.

Yeah for info, it's mostly cleaning, the update has changed a bit more.

[ia3andy]

@aloubyansky I think we can merge this PR as it contains a lot of fixes and should be available asap. I've fixed all backward compatibility and api issues which were important.

There is a plan for the info command (that we should do in another PR): #46460

Please let's not block this PR longer as it contains things that some people are waiting for.

[aloubyansky]

I wanted Guillaume to review it at least on the high level

[ia3andy]

@gsmet discussed the update part on Zulip so he's aware of most of it.

For the info part, this is just the premises. It's not taking more resources than the previous version which was already checking for alignement (just not showing the info by default).

Guillaume, let me know if you want me to hold it longer if you want to spend more time on the review (I'll wait this afternoon to merge).

[ia3andy]

@gsmet is that too large to be backported to 3.19?

[wjglerum]

1. This change removes the per-module option (but not the code handling it). The per-module option was supposed to be logging discovered Quarkus info per module in a multi module project (even if a module isn't an application but configured some Quarkus-related dependencies). I don't think it's a big deal, since I don't think this option was very popular any way and I think it would require more work to make it truly useful.

@ia3andy thanks for all the updates and improvements! Like the new experience of updating!

It does look like quarkus update no longer works in a multi module maven project, it just says it can't find any quarkus extensions in the main build (which is true as they are in a subproject).

No Quarkus extensions were found among the project dependencies

Running ./mvnw quarkus:update does still work for me to update the multi module project. Any chance we can get the --per-module back again to update multi module projects by simply running quarkus update? Also, do you want me to open a new issue for it?

[ia3andy]

1. This change removes the per-module option (but not the code handling it). The per-module option was supposed to be logging discovered Quarkus info per module in a multi module project (even if a module isn't an application but configured some Quarkus-related dependencies). I don't think it's a big deal, since I don't think this option was very popular any way and I think it would require more work to make it truly useful.

@ia3andy thanks for all the updates and improvements! Like the new experience of updating!

It does look like quarkus update no longer works in a multi module maven project, it just says it can't find any quarkus extensions in the main build (which is true as they are in a subproject).

No Quarkus extensions were found among the project dependencies

Running ./mvnw quarkus:update does still work for me to update the multi module project. Any chance we can get the --per-module back again to update multi module projects by simply running quarkus update? Also, do you want me to open a new issue for it?

Hello, I don't think that quarkus update ever worked on multi-module because it's adding the option to only run on the given pom. We are investigating removing that option to allow running on the multi-module, @aloubyansky I think has started something.

[aloubyansky]

If it's a regression then, imo, we should fix it.
What I'm working on on a side is pretty much a re-write. It won't appear as a quick fix.

[ia3andy]

I don't think this has ever been working from the CLI, I haven't changed this behaviour (AFAIK). The --per-module option was calling the info instead of updating.

[wjglerum]

I don't think this has ever been working from the CLI, I haven't changed this behaviour (AFAIK). The --per-module option was calling the info instead of updating.

I'll have to go an try some versions again, I know it wasn't working at all in the past but in more recent versions I have been able to use it afaik.

I'm off this afternoon but can try out some things again tomorrow probably.

[aloubyansky]

@wjglerum it'd be great if you could confirm whether it's a regression and/or provide enough details to reproduce it.
Having details to reproduce we can try different versions on our side.

[wjglerum]

@wjglerum it'd be great if you could confirm whether it's a regression and/or provide enough details to reproduce it. Having details to reproduce we can try different versions on our side.

So just gave this another try, updating my multi module project with quarkus update from 3.18.x to 3.19.x works with Quarkus CLI 3.19.1, and it executes the migrations on all the subprojects. Reverting the changes and running quarkus update with Quarkus CLI 3.19.2 does nothing:

No Quarkus extensions were found among the project dependencies

However quarkus info does detect all the sup projects and reports on the used quarkus extensions with Quarkus CLI 3.19.2

Alos ruunning the update with Maven does still work with Quarkus 3.19.2:
./mvnw quarkus:update
And it executes it on all subprojects

[ia3andy]

Thanks for testing, it helps a lot. I will give it another second look, i must have changed something by mistake..