openrewrite / rewrite-quarkus Goto Github PK

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#avro

Avro has been integrated with the Quarkus code generation mechanism. To use it with Maven, make sure you have the generate-code goal enabled for the quarkus-maven-plugin, it should be enabled by default if you created your project fairly recently. For Gradle no specific task is required.

This replaces the need to use Avro plugin, such as the avro-maven-plugin, for projects that use Avro.

Given the 2.x release, https://github.com/quarkusio/quarkus/releases/tag/2.0.0.Final
Based on https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0
https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#jandex-upgrade

We fixed some issues related to the Jandex indexer. Jandex itself is part of our BOM so will be upgraded automatically but if you use some Jandex build plugins, you need to upgrade them yourself.

If you are using the Jandex Maven plugin, please upgrade it to 1.1.0.
If you are using the Jandex Gradle plugin (org.kordamp.gradle.jandex), please upgrade it to 0.11.0.

@ammachado provided a very nice pull request to support adding Quarkus properties to config files.

This is awesome and solves part of the problem but one thing that we often have to deal with Quarkus updates is to actually rename a config property.

What problem are you trying to solve?

We would like to be able to rename a configuration property key in Quarkus config files, be they in YAML or .properties.

Currently, we are doing the following:

type: specs.openrewrite.org/v1beta/recipe
name: io.quarkus.updates.core.quarkus33.ApplicationProperties
recipeList:
  - org.openrewrite.properties.ChangePropertyKey:
      oldPropertyKey: quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy
      newPropertyKey: quarkus.hibernate-search-orm.indexing.plan.synchronization.strategy
  - org.openrewrite.properties.ChangePropertyKey:
      oldPropertyKey: quarkus\.hibernate-search-orm\.(.+)\.automatic-indexing\.synchronization\.strategy
      newPropertyKey: quarkus.hibernate-search-orm.$1.indexing.plan.synchronization.strategy
      regex: true
preconditions:
  - org.openrewrite.FindSourceFiles:
      filePattern: "**/application*.properties"

#####
# Adjust properties in application.yml/yaml
#####
---
type: specs.openrewrite.org/v1beta/recipe
name: io.quarkus.updates.core.quarkus33.ApplicationYml
recipeList:
  - org.openrewrite.yaml.ChangePropertyKey:
      oldPropertyKey: quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy
      newPropertyKey: quarkus.hibernate-search-orm.indexing.plan.synchronization.strategy
preconditions:
  - org.openrewrite.FindSourceFiles:
      filePattern: "**/application*.y*ml"

This example is interesting because it shows all the limitations of this approach:

• we have a recipe for .properties and a recipe for YAML. For each configuration property renaming, we need to do both
• renaming a configuration property in YAML actually doesn't work. In Quarkus, each . will need to be split in a separate YAML key as done in AddQuarkusProperty. org.openrewrite.yaml.ChangePropertyKey is generic and doesn't take into account this specificity
• some properties, such as this one, have a default entry quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy but can also be used as named entries such as quarkus.hibernate-search-orm."name of the persistence unit".indexing.plan.synchronization.strategy. We handled it for properties but not for YAML. Note that I think it should be a separate recipe as it's impossible to know where the map key part will be in the configuration property key: we need to pass this knowledge somehow to the recipe. Note that the map key is not always surrounded by quotes. As long as it doesn't contain any special characters, it's perfectly valid.
• we do not handle configuration profiles. Properties can be prefixed with profiles, such as %dev.<the property>, %dev,prod.<the property>. In YAML, you would have a leading %dev: key.

One other thing we might want to consider would be to also rename entries in .env but we would need to clarify the rules to get from the configuration property to a matching env variable. I think we could do that in a separate step.

Describe the situation before applying the recipe

quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy=test
%dev.quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy=test
%dev,prod.quarkus.hibernate-search-orm.automatic-indexing.synchronization.strategy=test

quarkus.hibernate-search-orm."unitname".automatic-indexing.synchronization.strategy=test
%dev.quarkus.hibernate-search-orm."unitname".automatic-indexing.synchronization.strategy=test

Describe the situation after applying the recipe

quarkus.hibernate-search-orm.indexing.plan.synchronization.strategy=test
%dev.quarkus.hibernate-search-orm.indexing.plan.synchronization.strategy=test
%dev,prod.quarkus.hibernate-search-orm.indexing.plan.synchronization.strategy=test

quarkus.hibernate-search-orm."unitname".indexing.plan.synchronization.strategy=test
%dev.quarkus.hibernate-search-orm."unitname".indexing.plan.synchronization.strategy=test

For YAML, that would be the exact same thing with each part of the key split by . (but ideally, we would need to be careful as you could have things like "my map key with a . dot").

as per https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#reactive-routes
see https://github.com/quarkusio/quarkus-quickstarts/pull/828/files

The enum of the HTTP verb to configure the methods attribute of a @route has been moved to io.quarkus.vertx.web.Route.HttpMethod.

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#smallrye-jwt

Logging just for issue-tracking purposes

smallrye.jwt.sign.key-location has been renamed to smallrye.jwt.sign.key.location and smallrye.jwt.encrypt.key-location - to smallrye.jwt.encrypt.key.location.

As per https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#kubernetes-client

The Kubernetes Client has been upgraded to 5.4, which contains some breaking changes.
Please refer to the release notes for more details. https://github.com/fabric8io/kubernetes-client/releases/tag/v5.4.0

Logging this as an item to show a known limitation, ie this recipe will not do a full general-purpose fabric8io/kubernetes-client 5.4.0 migration. Can close at any time, logging for issue-tracking.

Add recipe for converting multi.transform().toHotStream() -> multi.toHotStream()

The .env file at the root of a Quarkus project can contain environment variables that configures Quarkus and so can contain env var version of the properties.

For instance QUARKUS_MY_PROPERTY or _DEV_QUARKUS_MY_PROPERTY for something that is only enabled for the dev profile.

The rule is basically that any letter will be uppercased, numbers will be left alone and anything else will be transformed to _.

Note that while simple cases might be manageable, I'm not entirely sure how we will be able to handle regexps. We might be able to handle the most common cases (and make sure we catch errors if the transformed regexp is invalid).

One difficulty will be that my-property has to be changed to MY_PROPERTY but [a-z] shouldn't be affected. Also - can be used at the end of a class of characters and in this case, it is just a - that should be replaced.

What problem are you trying to solve?

Looking to create a generic JavaEE to Quarkus 2 composite recipe who's primary purpose would be to move off EJBs. Planning on incrementally contributing to various parts of the upgrade. Will start with Adding Quarkus dependencies, removing JEE dependencies and converting Stateless, Stateful and Singleton EJBs to reasonable defaults on CDI. Eventually planning on upgrading Message Driven Beans to Camel Quarkus JMS/ActiveMQ, EJB Schedules to Quarkus Scheduler

What precondition(s) should be checked before applying this recipe?

That it is in-fact a JavaEE (Not JakartaEE) application to begin with

Describe the situation before applying the recipe

Working JavaEE application

Describe the situation after applying the recipe

Ideally, a fully transformed and working Quarkus 2 application

Are you interested in contributing this recipe to OpenRewrite?

Yes. Would be looking for feedback on best practices. I would like to stick to as many Declarative recipes as possible.

SmallRye ConfigMappings

A Config Mapping requires an interface with minimal metadata configuration:

@ConfigMapping(prefix = "server")
interface Server {
    String host();

    int port();
}

Quarkus @ConfigProperties are allowed on classes while @ConfigMapping is only valid for interfaces
https://quarkus.io/guides/config-reference#using_configproperties
https://quarkus.io/guides/config-reference#additional-notes-on-configproperties

This task is to refactor @ConfigProperties configuration classes and associated variable references annotated with to interfaces and methodInvocations

before:

import io.quarkus.arc.config.ConfigProperties;

@ConfigProperties(prefix = "greeting")
public class MyConfiguration {
    String message;
    String name;
}
public class MyService {
  @Inject
  MyConfiguration myConfig;
  
  String getName() {
    return myConfig.name;
  }
}

after:

import io.smallrye.config.ConfigMapping;

@ConfigMapping(prefix = "greeting")
public interface MyConfiguration {
    String message();
    String name();
}
public class MyService {
  @Inject
  MyConfiguration myConfig;
  
  String getName() {
    return myConfig.name();
  }
}

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-1.12#mailer

The MailTemplateInstance now returns a Uni instead of CompletionStage. To convert a Uni to a CompletionStage, call .subscribeAsCompletionStage().

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-1.13#jackson

SerializationFeature.WRITE_DATES_AS_TIMESTAMPS is now disabled by default which means your temporal types will be serialized as strings (e.g. 1988-11-17T00:00:00Z) starting 1.13, instead of numeric values.

You can easily go back to the previous behavior by adding quarkus.jackson.write-dates-as-timestamps=true to your application.properties.

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-1.13#removal-of-the-native-image-maven-goal

Please remove the plugin execution from your pom.xml and simply add the following property to your native profile:

<properties>
    <quarkus.package.type>native</quarkus.package.type>
</properties>

Such as Mutiny API migrations which execute as part of 1.{11,12,etc} -> 1.13.7, etc.

@ammachado in the configuration properties recipes, we say that the elements can be regexp but in fact they always are, right?

So if you want to replace quarkus.something key, you actually need to define quarkus\.something or you will also replace quarkuswsomethingor quarkus-something.

This makes things a bit more complex than they need to be and also not in line with https://docs.openrewrite.org/recipes/properties/changepropertykey where you have this regex boolean to actually enable regexp transformation.

I wonder if we should change the current behavior to avoid regexps in the default case and only enable regexps when regex is set to true.

That would be a breaking change but I think these recipes are new enough that it's worth breaking them to be consistent with the rest of OpenRewrite.

I thought about that because I was migrating old Quarkus Update recipes to this new stuff.

WDYT?

/cc @timtebeek for advice.

Qute

The deprecated annotations from the io.quarkus.qute.api package were removed. All occurrences of @io.quarkus.qute.api.CheckedTemplate should be replaced with @io.quarkus.qute.CheckedTemplate and occurrences of @io.quarkus.qute.api.ResourcePath should be replaced with @io.quarkus.qute.Location.

Checked templates require type-safe expressions by default, i.e. expressions that can be validated at build time. It's possible to use @CheckedTemplate(requireTypeSafeExpressions = false) to relax this requirement.

Multiple NamespaceResolver instances can be registered for the same namespace provided that each declares a different priority.

As per https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#vertx

Quarkus 2.0 uses Vert.x 4.0. If your application relies on Vert.x APIs, check the Vert.x migration guide. https://vert-x3.github.io/vertx-4-migration-guide/index.html

Logging this as an item to show a current known limitation, ie as it is, this recipe will not do a vertx 3->4 migration. Can close at any time, logging for issue-tracking.

Issue is likely better suited to live in the rewrite-maven core project, feel free to move at any point. Optimizing for speed at the moment.

In order to upgrade quarkus 1.11 to 1.12, evaluate why quarkus 1.12 is not available to the UpgradeDependencyVersion visitor. For more info openrewrite slack channel thread about this

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-1.12

• the version of the quarkus-maven-plugin should be bumped to 2.x -- An especially useful implementation of the ability to update plugin versions update is contingent on openrewrite/rewrite#585 details discussed in openrewrite/rewrite#579
• generate-code and generate-code-tests goals should be added

We cleaned up a few things in the Quarkus Maven Plugin. Make sure the quarkus-maven-plugin section of the pom.xml of your project looks like:

<plugin>
  <groupId>io.quarkus</groupId>
  <artifactId>quarkus-maven-plugin</artifactId>
  <version>${quarkus-plugin.version}</version>
  <extensions>true</extensions>
  <executions>
    <execution>
      <goals>
        <goal>build</goal>
        <goal>generate-code</goal>
        <goal>generate-code-tests</goal>
      </goals>
    </execution>
  </executions>
</plugin>

The deprecated config value StoreType.DB was removed. quarkus.quartz.store-type=db should be replaced with quarkus.quartz.store-type=jdbc-cmt

Mutiny has deprecated a few APIs. The deprecated APIs are still available and would work, but are planned for removal.
Changed APIs are:
- multi.collectItems() -> multi.collect()
- multi.groupItems() -> multi.group()
- multi.transform().byTakingFirstItems(long)/byTestingItemsWith()/byFilteringItemsWith() -> multi.select().first(long), multi.select().when(Function<T, Uni<?>>), multi.select().where(Predicate)
- multi.transform().toHotStream() -> multi.toHotStream()
- multi.transform().bySkippingFirstItems(long) -> multi.skip().first(long)
Mutiny removes two methods (deprecated for 11 months):
- uni.subscribeOn -> uni.runSubscriptionOn()
- multi.subscribeOn -> multi.runSubscriptionOn()

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#smallrye-config

Quarkus @ConfigProperties has been deprecated in favor of SmallRye Config @ConfigMapping.

Quarkus configuration Interfaces annotated with@ConfigProperties can easily be converted by replacing the @ConfigProperties annotation with the @ConfigMapping annotation.

This task is for a ChangeType visitor to be applied on interfaces annotated with @ConfigPropreties.

Converting @ConfigProperties annotated classes has been moved to a new issue.
#24

Refactor recipe for removing avro-maven-plugin to conditionally remove the plugin based on whether quarkus is being used.

As in-- avro-maven-plugin will only be removed if the quarkus-maven-plugin is also found.

In Quarkus, we also support profile-aware files for application.properties and application.ya?ml.

For instance, configuration properties in application-dev.properties are only enabled for the dev profile.

When updating properties, we should take these files into account by default.
When targeting a specific profile, we should only change the files which target the given profile.

@ammachado I think I mentioned this when you worked on these recipes but I don't remember what was the conclusion?

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-1.13#live-reload-instrumentation

quarkus.dev.instrumentation has been renamed to quarkus.live-reload.instrumentation to be more consistent with other configuration properties related to live reload.

as per https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#kafka
see: quarkusio/quarkus-quickstarts@9504e36

Accessing the default configuration of the Kafka broker must use the Identifier annotation, instead of Named:

    @Named("default-kafka-broker")

->

    @Identifier("default-kafka-broker")

Create a new repository for this.

Migration guides
https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0

2.0 release is coming out soon (June).

Demo repository is still on 1.11.
https://github.com/cescoffier/reactive-coffeeshop-demo/blob/master/pom.xml

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-2.0#grpc

gRPC service classes now have to be annotated with @io.quarkus.grpc.GrpcService instead of @javax.inject.Singleton.

This quarkus guide may be helpful for identifying gRPC service classes: https://quarkus.io/guides/grpc-getting-started

What problem are you trying to solve?

Gradle dependencies are not replaced; only Maven.

Describe the solution you'd like

Swap out the Maven specific recipes for generic recipes from rerwite-java-dependencies, as seen on

• openrewrite/rewrite-logging-frameworks#123

https://github.com/quarkusio/quarkus/wiki/Migration-Guide-1.13#removal-of-the-maven-uberjar-and-gradle---uber-jar-parameters

If using uberJar-related parameters, add quarkus.package.type=uber-jar to the application.properties (or pom.xml, gradle, etc.):

Both the Maven uberJar and the Gradle --uber-jar parameters had been deprecated since 1.11.2.Final/1.12.0.CR1 and have now been removed in 1.13.

As a replacement, add quarkus.package.type=uber-jar to your application.properties (or e.g. pom.xml).