chore(build): generate a Jandex index in the Flow runtime modules instead of the aggregate flow-jandex artifact - #25899
Conversation
Each module now writes its own META-INF/jandex.idx, instead of relying on flow-jandex, an aggregate artifact that indexed the classes of seven other jars. That aggregate had to be kept in sync by hand - flow-react, flow-polymer-template, flow-webpush and vaadin-dev-server were missing from it - and it makes Jandex consumers attribute classes to an archive that does not contain them, which is what the Quarkus extension works around when it drops one of the overlapping Vaadin index artifacts. flow-jandex is kept as an empty artifact so that builds declaring it keep resolving.
The index is written at process-classes, before shade relocates the asm and commons packages, so the shaded artifact would carry an index naming classes that are no longer in it - the same reason the native-image configs are already filtered out. The unshaded main artifact keeps its index.
| <packaging>jar</packaging> | ||
| <name>Flow Jandex index</name> | ||
| <description>Jandex index for flow packages for when the vaadin platform is not used</description> | ||
| <description>Deprecated and empty: every Flow module now carries its own Jandex index. Kept so that builds depending on this artifact keep resolving; remove the dependency.</description> |
There was a problem hiding this comment.
Done — the module is gone: directory deleted, dropped from the reactor in the root POM and from flow-bom, so com.vaadin:flow-jandex is no longer published. Builds that declare it have to remove the dependency and take the index from the module jars instead. The full reactor still builds, and guidelines/repository.md now documents that every module jar carries its own META-INF/jandex.idx.
One thing to be aware of before this is merged: dropping the artifact in a minor is a hard resolution failure, not a warning, for any build that still declares it — the Quarkus extension's integration tests do, for example. If you'd rather not break those mid-cycle, the alternative is to keep flow-jandex publishing an empty jar until 26; happy to restore that if you prefer.
Every module now carries its own META-INF/jandex.idx, so the aggregate index artifact has nothing left to publish. The artifact is gone from the reactor and from the BOM; builds that still declare com.vaadin:flow-jandex have to drop the dependency, and get the index from the module jars instead.
| <!-- Dependency Maven metadata --> | ||
| <exclude>META-INF/maven/**</exclude> | ||
| <!-- Jandex index (references unshaded class names) --> | ||
| <exclude>META-INF/jandex.idx</exclude> |
There was a problem hiding this comment.
Is there a jandex index that reference the correct class names?
There was a problem hiding this comment.
There wasn't — the exclusion alone left the shaded artifact with no index at all. Now there is one: a jandex-jar execution regenerates the index inside the shaded jar after shade has run, so every name in it is post-relocation. Checked on the built artifact: 136 classes indexed, 7 signature references to com.vaadin.frontendtools.internal.asm.*, and none to org.objectweb.asm or org.apache.commons.
The relocated copies of asm/commons themselves are excluded from the index — they're bundled internals rather than classes this module publishes, and indexing them too would grow the artifact by ~330 kB instead of the ~39 kB it costs now. Say the word if you'd rather index the whole jar.
The index the parent POM writes at process-classes names the unshaded classes, so it is filtered out of the shaded artifact. Generate the index into that jar once it is packaged instead, so its signatures name the relocated asm and commons classes the jar actually contains. The relocated copies themselves stay out of the index: they are bundled internals, and indexing them would add some 330 kB to the artifact.
|
Test modules do not require a Jandex index to be created. |
Declare jandex-maven-plugin in pluginManagement and let the runtime modules an application puts on its classpath opt in: flow-server, flow-data, flow-html-components, flow-dnd, flow-lit-template, flow-polymer-template, flow-react, flow-webpush and vaadin-dev-server. Test and build-tool modules, vaadin-cdi and vaadin-spring have no Jandex consumer, so they no longer carry an index. That also leaves the shaded flow-build-tools jar without one, so its post-shade indexing goes away.
|
@mcollovati Agreed — the index is now opt-in. Test modules, build tooling, |
|
Wouldn't it be easier to use the skip property of jandex? |
Declare jandex-maven-plugin once in the parent's plugins with jandex.skip defaulting to true, and have the modules a Quarkus application loads set it to false, instead of each of them declaring the plugin.
|
@Artur- Yes, that's simpler — switched to it. The plugin is declared once in the parent's |
Default jandex.skip to false and set it to true in the modules without a Jandex consumer: flow-tests (inherited by every integration test module), flow-plugins, flow-build-tools, flow-devloop-daemon, flow-polymer2lit, the test utilities, vaadin-cdi and vaadin-spring. A new runtime module now gets an index without having to ask for one.
|
|
I think we can merge this one. flow-jandex removal should only affects Side note: jandex per artifact will also be helpful in the process of merging vaadin-quarkus into Flow codebase, because running I'll investigate what changes must be done in platform, then I think we can merge this and finalize with #25736 |
|
@mcollovati Thanks. No code change for this one; a note for the follow-ups. On the |
|
To be merged after vaadin/platform#9518 |
|
@mcollovati Noted, no change needed here. Once vaadin/platform#9518 lands, the aggregate indexes skip the jars that now carry their own index, so merging this afterwards avoids indexing Flow classes twice in the meantime. |



Summary
Each Flow runtime module now builds its own Jandex index (
META-INF/jandex.idx) for its own classes. This replacesflow-jandex, a separate artifact that indexed classes from other jars. That artifact had to be kept in sync by hand and made Quarkus link classes to a jar that did not contain them.What changed
Breaking: the
com.vaadin:flow-jandexartifact is removed from the reactor and fromflow-bom. Builds that declare it must drop the dependency, because the index now ships in the module jars. This affects only projects that use Flow outside the Vaadin Platform and depend onflow-jandexdirectly, such as Quarkus setups.pom.xmldeclaresjandex-maven-plugin(3.6.0) once, for all modules. The newjandex.skipproperty defaults tofalse, so a new runtime module gets an index automatically.jandex.skiptotrue:vaadin-springandvaadin-cdiflow-plugins,flow-build-tools,flow-devloop-daemon,flow-polymer2litflow-push,flow-client,flow-server-production-modeflow-tests, which passes the setting on to every integration test moduleflow-server,flow-data,flow-html-components,flow-dndandflow-lit-template. Also indexed areflow-react,flow-polymer-template,flow-webpushandvaadin-dev-server. The old aggregate did not include these four.guidelines/repository.mdremovesflow-jandexfrom the module list and explains which modules have an index and why.