RecordBuilder.Includes as a compilerArg

[giampaologrieco-oviva]

It would be great if there was the possibility to specify RecordBuilder.Includes as a compilerArg in the same way it already is for RecordBuilder.Options.

It would allow to have all the configuration in the pom.xml removing all the dependencies in the code (except at build time for the processor).
I hope it could be taken in consideration as an idea for an improvement.

[Randgalt]

Unfortunately this won't work. The Java annotation processor would not call Record Builder as there isn't an annotated class. There must be some annotated class for Record Builder to get called during compilation.

[giampaologrieco-oviva]

At the moment it perfectly works for me without annotating any java record class.

I only created a configuration class specifying the package to scan:

@RecordBuilder.Include(packages = "my.company.application.domain.model")
public class RecordBuilderConfiguration {}

The remaining configuration is here (it triggers the Record Builder)

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>${maven.compiler.plugin.version}</version>
                <configuration>
                    <source>${maven.compiler.source}</source>
                    <target>${maven.compiler.target}</target>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>io.soabase.record-builder</groupId>
                            <artifactId>record-builder-processor</artifactId>
                            <version>${record.builder.version}</version>
                        </path>
                    </annotationProcessorPaths>
                    <compilerArgs>
                        <compilerArgs>
                            -AenableGetters=false
                        </compilerArgs>
                        <compilerArgs>
                            -AprefixEnclosingClassNames=false
                        </compilerArgs>
                        <compilerArgs>
                            -AenableWither=false
                        </compilerArgs>
                    </compilerArgs>
                </configuration>
            </plugin>

I think providing the package as a compilerArg also is possible and it will prevent me for having to create any Configuration class into the code.

[Randgalt]

If you have to have RecordBuilderConfiguration does putting the includes in the POM help? You'd prefer them there to having them in code?

[giampaologrieco-oviva]

If you have to have RecordBuilderConfiguration does putting the includes in the POM help? You'd prefer them there to having them in code?

Exactly. The goal of this question is the possibility to get rid of the RecordBuilderConfiguration.

In this case the configuration can be completely contained inside the pom.xml and we can leave the code completely untouched.

[Randgalt]

The goal of this question is the possibility to get rid of the RecordBuilderConfiguration

That's what I'm trying to say. If you don't have that RecordBuilderConfiguration then Record Builder will never get called. There must be some annotated class so that the java compiler calls Record Builder's processor. Other annotations in your code might trigger Record Builder but that seems fragile to me.

[giampaologrieco-oviva]

The goal of this question is the possibility to get rid of the RecordBuilderConfiguration

That's what I'm trying to say. If you don't have that RecordBuilderConfiguration then Record Builder will never get called. There must be some annotated class so that the java compiler calls Record Builder's processor. Other annotations in your code might trigger Record Builder but that seems fragile to me.

Ok, I got it.
So the only viable way in my opinion is having 2 compilerArgs:

• the first one is to indicate the annotation to trigger the processor (it is used only for triggering)
• the second one is to indicate the package(s) you want to scan for generation

being able to specify the annotation itself makes the solution less fragile maybe

[Randgalt]

indicate the annotation to trigger the processor

That isn't necessary - Record Builder's processor is called for every annotation that javac sees which is why this is always going to be weird. In 90% of java projects there's at least one annotation. But, there will always be projects that have no annotations and then this doesn't work. It smells funny to me.

A reasonable compromise is to require that 1 instance of @RecordBuilder.Include be present somewhere in the project. Maybe we'd add a new attribute, boolean useOptions(). So, you'd have a single @RecordBuilder.Include on a single class and then all the include classes, etc. could be specified in the build (POM, gradle) file.

[giampaologrieco-oviva]

Thank you for your answers Randgalt!

indicate the annotation to trigger the processor

That isn't necessary - Record Builder's processor is called for every annotation that javac sees which is why this is always going to be weird. In 90% of java projects there's at least one annotation. But, there will always be projects that have no annotations and then this doesn't work. It smells funny to me.

Yes, that's why I proposed to force to declare one (but in that case @RecordBuilder.Include in a configuration class could be viable).

Another solution is to permit the processor to scan also the record-builder.jar library itself as source code.
In the library there could be a class with the @RecordBuilder.Include to trigger the processor.
The rest of the configuration stays in the pom/gradle
(or even the runtime java library for an annotation?)

A reasonable compromise is to require that 1 instance of @RecordBuilder.Include be present somewhere in the project. Maybe we'd add a new attribute, boolean useOptions(). So, you'd have a single @RecordBuilder.Include on a single class and then all the include classes, etc. could be specified in the build (POM, gradle) file.

I already have a single class where the @RecordBuilder.Include is, so it will not give any advantage except of moving the option of the packages to scan from the class to the pom.xml.
The point here is to be able to not modify the code at all and to not be forced to add an empty configuration class with the only reason to trigger the build.

[Randgalt]

permit the processor to scan also the record-builder.jar library itself as source code

Annotation processing is done by javac. There is no mechanism to do what you describe. Annotation processing happens at compile time as javac processes .java files.

[giampaologrieco-oviva]

Thank you Randgalt,

I see now it is not possible to achieve what I asked with an annotation processor.
thank you again for your time and for your explanation.