Ravel implements the standard MicroProfile Config 3.1 contract. Application code written against the spec — ConfigProvider.getConfig(), @ConfigProperty, ConfigSource, Converter — ports without change. Migration effort is concentrated in build configuration and in dropping vendor-specific extensions.

From SmallRye Config

SmallRye Config Ravel Note

ConfigProvider.getConfig()

Same

Standard MicroProfile Config entry point. No change.

@ConfigProperty

Same

Standard injection. No change.

Custom ConfigSource / ConfigSourceProvider

Same SPI

Re-register through META-INF/services; ordinals are preserved.

Custom Converter with @Priority

Same SPI

Identical contract.

@ConfigMapping interfaces

Not in MP Config 3.1

SmallRye-specific. Replace with @ConfigProperty fields or programmatic lookup.

io.smallrye.config.* extensions (interceptors, secret keys, …)

Not applicable

Vendor extensions; refactor onto the standard SPI.

Migration steps

  1. Replace the SmallRye Config dependency with io.vidocq.ravel:ravel-api (+ ravel-core, and ravel-cdi-vauban for CDI) — see Reference.

  2. Keep your microprofile-config.properties, custom sources and converters unchanged.

  3. Replace any @ConfigMapping interface with @ConfigProperty fields or a programmatic ConfigBuilder (see Usage).

  4. Add a module-info.java requiring org.eclipse.microprofile.config (Ravel is strict JPMS).

  5. Verify ordinal precedence and active profile behave as expected (see Concepts).

Pitfalls

  • @ConfigMapping — not part of MicroProfile Config 3.1; no direct equivalent. Refactor to @ConfigProperty.

  • Vendor interceptors / secret handling — SmallRye-only; reimplement on the standard ConfigSource/Converter SPI.

  • Implicit module names — a SmallRye jar on the classpath relied on automatic modules; Ravel requires explicit requires clauses.

  • Expression syntax — Ravel honours the spec ${key} / ${key:default}; non-standard interpolation features are not supported.

Going further