Support for Quarkus 3.15 LTS

[toco-cam]

Acceptance Criteria (Required on creation)

Update Quarkus to 3.x LTS release.

Hints

• We will update Quarkus to 3.14 at the end of August and try to bump it to 3.15 after our code freeze (best effort).
• Quarkus 3.15 LTS will be released on September 25th: https://quarkus.io/blog/next-lts-3-15/#quarkus-3-15

Links

Breakdown

Tasks

Preview Give feedback

1. Bump Quarkus to 3.14 #4579
   3 of 3
   type:subtask version:7.22.0 version:7.22.0-alpha6 +3
   
2. Bump Quarkus to 3.15 #4580
   6 of 6
   type:subtask version:7.22.0 +2
   

Dev2QA handover

• Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment

[tasso94]

Won't happen with 7.22.0 since Quarkus 3.15 is released after our code freeze.
@toco-cam, please update the customer about it.

[joaquinfelici]

Notes about upgrading

Upgrading to quarkus 3.14 or 3.15 requires some modifications in the way we implement configuration classes. This is because we're using the legacy behavior of using the @ConfigRoot annotation without a related @ConfigMapping annotation.

This leaves us with a few options:

1. Add a flag to allow for legacy behavior: By adding flag -AlegacyConfigRoot=true, we can keep the current behavior and upgrade with no issues. However, we don't know until when this flag and behavior will be supported, so migration might be enforced sooner or later.

2. Migrating to the new behavior: Best option to ensure future compatibility and smother version upgrades in the future. However, there's a behavior change in the way that quarkus now handles unnamed property maps, such as genericConfig. Because of this difference, we're left with two options:

   1. Change this map to a named property. This behavior is the recommended one in the quarkus documentation. This would mean having to replace all existing properties to include the new name of the property. For example, changing quarkus.camunda.cmmn-enabled=false to quarkus.camunda.generic-config.cmmn-enabled=false (see more examples in the documentation).
   2. Keeping this map as an unnamed property, which produces a difference in behavior as well, because all matching properties will be included in this map, including the specific ones defined in the class. This means that for example, the known property quarkus.camunda.datasource will be both set in the datasource property and in the genericConfig property, producing some unexpected behavior. A potential solution to this is a workaround to manually remove known properties.

[psavidis]

Assigning the ticket to @psavidis to continue the progress.

[tasso94]

Decision

1. Use the -AlegacyConfigRoot=true flag

• Pros:
  • Easy to implement.
  • No migration effort for users. And for us since we don't need to add something to the migration guide.
• Cons:
  • Unpredictability of support. I.e., Quarkus maintainers might remove this flag in future releases and we will be in the same situation again.
  • Assumption: the user has to pass this flag.

2. Migrate to the new config structure. I.e., generic configuration is prefixed with generic-config.

• Pros:
  • Our extension is future-proof. Once Quarkus maintainers remove the legacy flag, there will be no need to fiddle around with it again.
  • Straight forward: no custom implementation that might break in the future, and we have to maintain.
  • We do it similarly with Spring Boot; this is most likely how frameworks will handle it in the future.
• Cons:
  • Breaking change => users have to migrate configs; We have to provide a migration guide explanation.
  • A little bit more complex to implement compared to # 1.

3. Filter out generic configuration properties to maintain the previous configuration structure.

• Pros:
  • No migration effort for users and no migration guide contribution for us.
  • Low documentation complexity.
• Cons:
  • Unpredictability: Quarkus maintainers might introduce code changes that break our logic again.
    • Would be a big problem when introduced by a Quarkus patch.
    • Might be an acceptable risk when introduced by a Quarkus minor release.
  • Highest complexity to implement; we might need to test more thoroughly to ensure it works as expected.

4. To be investigated: is there any way to skip the "generic-config" in Quarkus 3.14 again?

Conclusion

• Option 3 has too much complexity and risk/uncertainty.
• Option 1 we just postpone the problem to a future point in time.
• Option 2 is preferred since we see the smallest risk, and maintenance effort, and we don't postpone having to fix this in the future again.

Let's do option 2.

[psavidis]

Investigation Update

Decision | Point 4

• Could not find a specific guideline in Quarkus Guide | Mapping Configuration to Objects
• The maps section indicates how a map-key can be mapped from a config file inside the map; however that means the key needs to be placed in quotes

quarkus.camunda.enforce-history-time-to-live=false

becomes

quarkus.camunda."enforce-history-time-to-live"=false

which does not prevent the migration

[psavidis]

Assigning to @mboskamp for doing the Review.

[tasso94]

Hey @psavidis, can you create another follow-up task to bump Quarkus to 3.15?

[psavidis]

Hey @psavidis, can you create another follow-up task to bump Quarkus to 3.15?

Split the ticket into separate tasks for upgrading to 3.14 and 3.15 versions respectivelly.

[mboskamp]

@psavidis, what is my current TODO with this ticket? You assigned #4579 to me for review, but since nothing in this ticket needs reviewing, I would suggest we keep your assignment since you are the DRI. WDYT?

[psavidis]

Update to Quarkus 3.14 is completed ✔️

Next step: Try the upgrade to Quarkus 3.15 after the code-freeze as a low-risk item and update this thread with the results of the task (positive or negative)

[psavidis]

Assigning to @joaquinfelici to continue the upgrade to 3.15 task in due time.

[joaquinfelici]

Upgrade to Quarkus 3.15.0 is done and merged on PR #4612.

Pending:

• Merge docs.
• Test during minor release.