Review usage of IndexDependencyBuildItem

[jamesnetherton]

We can probably restrict usage of IndexDependencyBuildItem to just native builds in a lot of cases, since we only use the Jandex index to discover classes for registering for reflection etc.

We should probably not unnecessarily bloat the index in JVM mode. Might help to save some CPU cycles during the augmentation phase.

[ppalaga]

If the given build step produces just reflection registrations (or other items required only by native target) then the build container should not be executing those for JVM target at all, no?

[jamesnetherton]

the build container should not be executing those for JVM target at all

Ah yes, of course.

I think something confused me where an extension had no native build steps but the indexing was still happening. I forgot about transitives that would be producing ReflectiveClassBuildItem etc.

So there's nothing to do here.

[jamesnetherton]

Actually, now that I've collected my thoughts a bit more....

This pattern is quite common in our extensions:

@BuildStep
IndexDependencyBuildItem index() {
    return new IndexDependencyBuildItem("org.foo", "foo");
}

@BuildStep
ReflectiveClassBuildItem reflectiveClass(CombinedIndexBuildItem combinedIndex) {
    Set<String> reflectiveClasses = combinedIndex.getIndex()
            .getAllKnownSubclasses(Foo.class)
            .stream()
            .map(ClassInfo::name)
            .map(DotName::toString)
            .collect(Collectors.toSet());
    return ReflectiveClassBuildItem
            .builder(reflectiveClasses.toArray(new String[0]))
            .build();
}

The index step would still run in JVM mode even though we only need it for the reflectiveClass step.