Support Alternate Loading of Generated SPIs

[SentryMan]

Noticed a bit of a problem when using the avaje-spi while using a generator that also writes to the same META-INF/services.

Adds functionality to load SPI information from an alternate directory so that service writing is unimpeded

[rob-bygrave]

load SPI information from an alternate directory

How does that work?

problem when using the avaje-spi while using a generator that also writes to the same META-INF/services.

Can you explain what exactly the issue was here?

[SentryMan]

How does that work?

Essentially, after the last round of annotation processing, we check the META-INF/generated-services directory for service entries generated from other annotation processors and then we write those into META-INF/services.

Can you explain what exactly the issue was here?

Since we've been consolidating SPI interfaces, I'm seeing collisions with the annotation processors when it comes to writing META-INF/services entries.

As an example, InjectPlugin now must be registered as InjectExtension, so using @ServiceProvider to registerInjectPlugins causes both the SPI processor and the Inject Processor to open and write to the same services file. (The Inject processor for regular modules, and the spi processor for the plugin)

[rob-bygrave]

As an example, InjectPlugin now must be registered

I don't understand yet. Are you saying that a project that is using avaje-inject AND ALSO has a custom InjectPlugin?

I don't understand the scenario?

[SentryMan]

I don't understand the scenario?

Think bigger, if you have a custom MessageInterpolator registered with @ServiceProvider along with regular avaje validation you hit the same issue. The same thing will also happen when we consolidate the Jsonb interfaces.

The issue is that two APT processors that try to create the same META-INF file. before we didn't have any issues since the generated classes had their own SPI and didn't interact with user provided SPI

[rob-bygrave]

Think bigger, if you have a custom MessageInterpolator registered with @Serviceprovider along with regular avaje validation you hit the same issue.

Don't afraid to be explicit and obvious. It isn't obvious to me.

How does the issue manifest. Which 2 Annotation processors? Which service interfaces are clashing here (I'm guessing 2 implementations of avaje-spi-processor BUT I don't want to guess ... so please be super explicit if you can).

[SentryMan]

I'm gonna run with validation as an example then

say I have two classes

@Valid
record TestClass(@NotBlank("{interpolated.message}") String s) {}

@ServiceProvider
public class CustomeMessageInterpolator implements MessageInterpolator {
...
}

the code will fail to compile.

the reason is that the validator processor writes GeneratedValidatorComponent to the META-INF/services/io.avaje.validation.spi.ValidationExtension, and then also the spi processor will also try to write to META-INF/services/io.avaje.validation.spi.ValidationExtension to add the CustomeMessageInterpolator which doesn't work as you can't open and write the same file twice

[rob-bygrave]

which doesn't work as you can't open and write the same file twice

What is the error that throws?

[SentryMan]

What is the error that throws?

javax.annotation.processing.FilerException: Attempt to reopen a file for path M:\Dev\avaje-javalin-API-example\target\classes\META-INF\services\io.avaje.validation.spi.ValidationExtension

[SentryMan]

it's the same issue I initially had when I did this: #19 (comment) before I got around it