Ideally avaje-inject-generator should not depend on avaje-inject

[agentgt]

A lot of folks are not aware of this but you should almost never use the actual annotation classes in an annotation processor even your own. BTW I only know of couple libraries that generally do this correctly: MapStruct, JStachio (mine) and I believe Micronaut (so don't feel bad). It is also probably why no one knows about Hickory (or the new MapStruct gemtools).

So why is it problematic? Well the annotation processor is not guaranteed to have classes loaded and if your annotation references other classes (e.g. has a Class<?> parameter ) that are not yours you will have issues especially and I mean especially if you are dealing with modularized projects.

So why have you guys not run into issues? Well because both Maven and I think gradle as well will simply move whatever dependencies that are in <annotationProcessorPaths> into the classpath during compilation. Otherwise all libraries that are referenced with requires (static or not) in module-info (and not in the annotationProcessorPaths) will be put in the module-path.

The above is one the reasons why <annotationProcessorPaths> is required for modular projects but it is seriously limited and technically not correct either: https://issues.apache.org/jira/browse/MCOMPILER-391 and https://issues.apache.org/jira/browse/MCOMPILER-412

Otherwise if avaje-inject-generator does not have dependencies just having avaje-inject-generator on the classpath will work and you would not need to do <annotationProcessorPaths> for modular projects and this is one of the big advantages to doing it the painful. BTW this is also why lots of annotation processors shade their deps but you can't really do that for annotations.

So how do you access your own annotations without using them directly? You have to load the TypeElement.

avaje-inject/inject-generator/src/main/java/io/avaje/inject/generator/Processor.java

Line 118 in 12eba7f

readScopes(roundEnv.getElementsAnnotatedWith(Scope.class));

Instead of Scope.class you are going to pass a TypeElement. To get the TypeElement you can either get it from the call process function or just call Elements.getTypeElement: https://docs.oracle.com/en/java/javase/11/docs/api/java.compiler/javax/lang/model/util/Elements.html#getTypeElement(java.lang.CharSequence)

Anyway that is easy and fine however it becomes a pain in the ass to get annotation parameters. That is where Hickory comes in (or mapstruct gemtools but you would have to shade it).
https://javadoc.io/static/com.jolira/hickory/1.0.0/net/java/dev/hickory/prism/package-summary.html

Hickory is an annotation processor that makes what are called prisms which you can access your annotations as though you are accessing them directly.

Anyway I normally would not bother even bringing all this up as yeah there is a work around ... manually register annotation processors...

But the project appears to not heavily dependent on its annotation core lib and is not a big change. In fact I could probably do a PR and do it myself if you are interested.

Furthermore it is technically the right way to do it and will prevent problems in the future as more folks embrace modularity.

[SentryMan]

annotation references other classes (e.g. has a Class<?> parameter ) you get a problem

Do you mean the whole MirroredTypeException thing where you need to catch and use the type mirror? Or something else?

Hickory

do you have a code sample I could view to see how accessing annotations works?

In fact I could probably do a PR and do it myself if you are interested.

Feel free my guy, I kinda want to see how it'd look.

[agentgt]

Do you mean the whole MirroredTypeException thing where you need to catch and use the type mirror? Or something else?

Yep. You can of course catch that and call whatever the method on it that gives you the mirrors. I didn't check to see if you are doing that.

Of course the above becomes moot if you use TypeMirror/TypeElement.

do you have a code sample I could view to see how accessing annotations works?

Yeah but just don't go look around too much in the code base or you will be horrified ( compiler module in the project is an older code base):

Registering prisms (you make the deps to the annotations provided and optional or shade the generated code like I did):

https://github.com/jstachio/jstachio/blob/main/compiler/jstachio-prisms/src/main/java/io/jstach/apt/prism/package-info.java

Here is some accessing JStacheInterfaces: https://github.com/jstachio/jstachio/blob/1648f5d5c724b427f286b059a0ef3e24000a5265/compiler/apt/src/main/java/io/jstach/apt/GenerateRendererProcessor.java#L212

However its confusing in my code base because I go lookup enclosing elements for annotations (findPrisms).

But to be honest the Javadoc on hickory explains it better than mode code:
https://javadoc.io/static/com.jolira/hickory/1.0.0/net/java/dev/hickory/prism/package-summary.html

[SentryMan]

So I just tried adding a module.info to my example project and got this error java.lang.NoClassDefFoundError: io/avaje/inject/spi/Module: io.avaje.inject.spi.Module pretty sure it's coming from over here.

Would the hickory thing fix that? Also I've been trying to figure out how to make it work for like an hour now. Do hickory and the prisms need to be in a separate module and shaded in? or can they work in the inject-generator module?

[agentgt]

Sadly Hickory is so old it does not have a module so I think that might be the issue. That is why in jstachio I shaded it in.

Otherwise I might be misunderstanding the problem. Let me reread your comment tomorrow and I’ll follow up.

[SentryMan]

Caused by: java.lang.NoClassDefFoundError: io/avaje/inject/spi/Module at io.avaje.inject.generator.ExternalProvider.init(ExternalProvider.java:18)

Don't think the problem is with hickory, the prisms generate fine. Module is an interface type from the core avaje-inject. When I make it not a provided dependency it compiles. See this branch.

Essentially, we use the serviceloader to auto detect modules at compile time. Eliminating the need to explicitly define @InjectModules. The generator has a hard dependency on the core inject.

[rbygrave]

should almost never use the actual annotation classes in an annotation processor

Yes. Now I'm sure I hit this with another annotation processor querybean-generator which generates query beans for ebean orm ... and I'm a tad confused because I'm sure I previously had avaje-inject-generator all working with modules BUT it definitely is not working today with later versions of maven, plugins, java etc.

The generator has a hard dependency on the core inject.

Well we can change that. We can change to not use the ServiceLoader but instead read the services files, get the element names of the other modules, and then read the provided components etc from @DependencyMeta (if we have that access via classpath which we sometimes don't and then we use the inject-maven-plugin) ... so we can remove the hard dependency on avaje-inject (although the Plugin doesn't come with the same meta data as yet).

Looking at the annotations, the only annotation that has attributes we read is @InjectModule and the rest are just markers. That suggests to me that it might be worth trying to go the TypeElement/TypeMirror route.

[agentgt]

@SentryMan I'm sorry I misread your comment. I understand the problem now. Let me try forking later today off your branch.

[SentryMan]

read the services files

Yeah, I'm gonna need a hint on how to do this. Filer can't read multiple resources from dependencies, and I tried doing something wacky with URL classloader and scanning jars for the service files, but no dice. Maybe we should just lean on the inject mvn plugin entirely for auto requires.

[agentgt]

I haven't looked at the code yet but I will say if you are offering an SPI (an interface) for hooking into code generation it really should not be in the avaje annotation module (however a quick glance at Module and that does not appear to be the case).

Hickory would help you get things out Module safely with our referencing the actual class.

If you are generating META-INF/services I'm not sure what the problem is there however for modular applications that will not work but usually the idea and I think the avaje doc says this is you just have to manually plug in some provider of providers in.

That is the SPI is more like a factory that returns a list of implementations and not a single implementation so that one only has to make one module-info entry instead.

e.g. the SPI should be more like:

public interface ModuleProvider {
   List<Module> modules();
} 

Then you generate one standard ModuleProvider implementation that the user then references in their module-info.

But that is just my quick opinion.

[SentryMan]

If you are generating META-INF/services I'm not sure what the problem is there however for modular applications that will not work but usually the idea and I think the avaje doc says this is you just have to manually plug in some provider of providers in.

This is a new feature to autodetect avaje modules from dependencies without the need to explicitly define them in @InjectModules. The module class is used at runtime to build the bean scope. If you want to quickly debug, you can use this test class to step through the processor code

[agentgt]

I'm looking at the code now. I really need to fork hickory and making it proper module. That is why you had so many problems initially. I'll do that later today.

I was able to avoid that by making my annotation processor module not have a module-info and then generating the module-info with moditect.

That is the annotation processor is classpath compiled by maven and the IDE.

[agentgt]

@SentryMan I'm working off your branch. Give me hopefully like an hour and I think I should have it possibly working.

[agentgt]

@SentryMan I see the major problem with ExternalProvider.

@rbygrave I'm not sure I know fully how it Module is supposed to work but I assume implementations are generated by the generator including the META-INF/services registration of Module? That is it is not a true SPI for end users correct?

I recommend that Module become an annotation and preferable not Module as that name has huge conflict.

Instead of generating Module implementations you will generate classes that have a Module annotation on them.

The Module annotation has all the methods on the interface.

The user then create a package and package-info lets call it "gen" using your documented example

@Modules({org.example.gen.ExampleModule})
package org.example.gen;

ExampleModule has the new Module annotation on it and is generated.

Then in module-info we have something like:

module org.example {
  requires io.avaje.inject;
  //provides io.avaje.inject.spi.Module with org.example.ExampleModule;
  //Instead we open 
  open org.example.gen;
}

Then you go fetch the annotation mirrors on org.example.gen in the annotation processor.

However I have a feeling the issue is cross compile lookup.

A project I know that does DI across modules and compile time is inverno so I might go check exactly how they deal with discovery across modules. I'm guessing module annotations unlike package annotations are generally public but maybe not.

[SentryMan]

Modules cannot become an annotation because it is used at runtime to wire beans. in any case, we can take out this part and use the inject maven plugin to read the provided classes.

[agentgt]

OK I will put a dummy implementation in for now and push my code so you can get see what I did.