Move GraalVM Metadata from Micronaut Core and Modules to GraalVM Reachability Metadata

[sdelamo]

Migrate metadata from Micronaut core for all the modules we support to https://github.com/oracle/graalvm-reachability-metadata

• Micronaut TOML
• Micronaut Elastic Search
• Micronaut JMX
• Micronaut Micrometer
• Micronaut GraphQL
• Micronaut GRPC
• Micronaut Jackson XML
• Micronaut JAX-RS
• Micronaut OpenAPI
• Micronaut Problem-JSON
• Micronaut Serialization
• Micronaut Microstream
• Micronaut Servlet
• Micronaut Spring
• Micronaut AOT
• Micronaut Gradle Plugin
• Micronaut Maven Plugin
• Micronaut AWS
• Micronaut Azure
• Micronaut Discovery Client
• Micronaut GCP
• Micronaut Kubernets
• Micronaut Oracle Cloud
• Micronaut Tracing
• Micronaut Data
• Micronaut Cassandra
• Micronaut MongoDB
• Micronaut Neo4j
• Micronaut R2DBC
• Micronaut Redis
• Micronaut SQL
• Micronaut Flyway
• Micronaut Liquibase
• Micronaut Groovy
• Micronaut Kotlin
• Micronuat JMS
• Micronaut Kafka
• Micronaut MQTT
• Micronaut NATS
• Micronaut RabbitMQ
• Micronaut ACME
• Micronaut Cache
• Micronaut Email
• Micronaut Hibernate Validator
• Micronaut ignite
• Micronaut Picocli
• Micronaut Security
• Micronaut Test
• Micronaut Reactor
• Micronaut RxJava2
• Micronaut RxJava3
• Micronaut Multi-tenancy
• Micronaut RSS
• Micronaut TOML
• Micronaut Views

[melix]

To be clear, the reachability metadata repository should talk about libraries themselves and not the transitives, as far as I understand. So when we say "migrate Micronaut SQL" for example, it actually means looking at the features we have, the configuration files we have, and split them across as many configuration files as we need for external modules (e.g if the configuration for Micronaut SQL talks about MariaDB, then the configuration to be migrated to the config repo is the configuration for MariaDB).

Configuration for Micronaut itself should remain in the modules.

[melix]

So, as soon as we do this, there are a few consequences which will require larger coordination.

1. first of all, moving to the metadata repository requires releasing a new version of the Gradle plugin and Maven plugin to enable the metadata repository. This, itself, could have consequences as it's going to transparently add metadata to existing builds. For example, enabling the repository on an existing, out of the box, project, shows that we get metadata for both Netty and Logback. This could accidentally break applications, although the hope is precisely the opposite.
2. every time a module is migrated, we will create a number of PRs on the GraalVM reachability metadata repository. Before we can release the module, those would have to be merged and a new version of the repository would have to be released.
3. A consequence of 2. is that we don't handle the rollout of fixes anymore: by moving the configuration from a Micronaut module to the metadata repository, we can't fix a native image building problem by upgrading a Micronaut module version: we will need to wait for metadata repository releases.
4. Another consequence of 2. is that the metadata repository version which is used defaults to the latest release when the Native Build Tools are released. So it also means that the metadata version is bound to our Maven or Gradle plugins, which depend transitively on the NBT release. Note, however, that users can override the default version of the repository, or use their own.
5. We can decide to ship our own metadata repository zip and use it in our build plugins, if it happens that we have to wait too often on metadata repository releases: the NBT plugins already support custom zips or URLs, so we could potentially override the default.
6. The responsibility of "making it work" is shifted to the end user, not the Micronaut modules: while Micronaut modules may ship with native image configuration, it should only be for their own code, not transitive dependencies. Therefore, knowledge about how to make library X or Y to work with native image is moved outside of Micronaut responsibility to the community (that's a direct consequence of the use of the metadata repository). This means that only the application of the NBT plugin, or the Micronaut GraalVM plugin will enable the use of this metadata. This isn't a problem per se: this is simply to recognize that the responsibility has shifted from the producer (Micronaut) to the consumer (the end user application).

A concrete problem is to understand whether we can start migrating our metadata and not do everything at once. At first glance, it should be possible, because use of the metadata repository doesn't disable use of metadata embedded into jar files (for good reasons, since each library should package it for its own classes, ideally). In case there are problems, there are flags which can be used on the NBT plugins side to disable metadata for a specific library, for example. We will probably need to document how to do it.