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 |
|---|---|---|
|
Same |
Standard MicroProfile Config entry point. No change. |
|
Same |
Standard injection. No change. |
Custom |
Same SPI |
Re-register through |
Custom |
Same SPI |
Identical contract. |
|
Not in MP Config 3.1 |
SmallRye-specific. Replace with |
|
Not applicable |
Vendor extensions; refactor onto the standard SPI. |
Migration steps
-
Replace the SmallRye Config dependency with
io.vidocq.ravel:ravel-api(+ravel-core, andravel-cdi-vaubanfor CDI) — see Reference. -
Keep your
microprofile-config.properties, custom sources and converters unchanged. -
Replace any
@ConfigMappinginterface with@ConfigPropertyfields or a programmaticConfigBuilder(see Usage). -
Add a
module-info.javarequiringorg.eclipse.microprofile.config(Ravel is strict JPMS). -
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/ConverterSPI. -
Implicit module names — a SmallRye jar on the classpath relied on automatic modules; Ravel requires explicit
requiresclauses. -
Expression syntax — Ravel honours the spec
${key}/${key:default}; non-standard interpolation features are not supported.
Going further
-
Getting started — add Ravel to a project.
-
Concepts — the configuration model.
-
TCK — conformance status.