The new Jmix 3.0 comes with the Aura Theme.
I believe there’s a real opportunity for a course on “Migrating Your Existing Theme to Aura.”
Surely I’m not the only one who found this challenging?
Regards
Felix
The new Jmix 3.0 comes with the Aura Theme.
I believe there’s a real opportunity for a course on “Migrating Your Existing Theme to Aura.”
Surely I’m not the only one who found this challenging?
Regards
Felix
Hi, Felix!
You are definitely not the only one to find this challenging, and that’s why.
Aura and Lumo aren’t two skins on one underlying variable system — they’re two separate design-token models that happen to ship in the same framework. Switching between them isn’t a config flag, it’s a re-theme.
Different namespaces. Aura uses a completely different namespace for its CSS variables than Lumo does. Lumo uses --lumo-* variables (--lumo-primary-color, --lumo-space-s), Aura uses its own --vaadin-*/--aura-* namespace (--vaadin-text-color, --vaadin-radius-m, --aura-accent-color-light). Nothing maps between them automatically — CSS built against Lumo tokens just silently resolves to nothing under Aura. It doesn’t error out, the UI just looks broken or falls back to bare defaults.
Different logic, not just different names. Lumo defines Primary, Error, Warning, and Success as separate semantic colors, each with accompanying text and contrast variants — every one hardcoded as a fixed set of static opacity steps (a 10% variant for badges, 50% for focus rings, 100% for the solid button color, plus its own text-color and contrast-color tokens). Every shade is its own hand-set token — a discrete, hand-authored palette.
Aura drops that for one accent-color, and most of its text/border colors aren’t hardcoded at all — they’re computed by default from the customizable --aura-contrast-level property, with reasonable values between 0 and 5 and a default of 1, using native CSS features like light-dark(), where Aura even calculates the light and dark values for some properties based on other color properties instead of you setting each by hand like in Lumo. So there’s no 1:1 target for something like --lumo-error-color-50pct in Aura — Aura isn’t modeling “shades of a fixed error color,” it’s modeling “contrast level applied to a background.” See: How to use color properties of the Aura theme in Vaadin
LumoUtility has no Aura equivalent. It’s a Java/CSS utility-class layer built specifically on Lumo’s tokens. Vaadin’s own documentation gives general styling guidance, including how to use Tailwind, but doesn’t specifically address migrating from LumoUtility to Aura — a gap confirmed by developers asking about it directly on Vaadin’s forum. Tailwind is the direction they point to instead, but that’s a different tool, not a drop-in swap. See: Utility Classes
The above means that migrating Lumo → Aura means manually hunting down every --lumo-* reference, every LumoUtility usage, and every place your CSS assumed Lumo’s static-step color model — then rebuilding it against Aura’s accent + computed-contrast model. There’s no automated path for any of it.
Regards,
Gleb
Thank you @gorelov for the detailled explanation.
Do you think this would be worth a little webinar “Migrating Your Existing Theme to Aura.” or is it just to individual ?
Regards
Felix