Exception during file creation from APT module

[AndreaScarselliAx]

Hi,

After upgrading spring-modulith-bom to version 1.4.0 or version 1.4.1, we are getting the following exception on CI.

Caused by: java.lang.IllegalArgumentException: directories not supported
    at com.sun.tools.javac.file.PathFileObject.<init> (PathFileObject.java:340)
    at com.sun.tools.javac.file.PathFileObject$DirectoryFileObject.<init> (PathFileObject.java:111)
    at com.sun.tools.javac.file.PathFileObject.forDirectoryPath (PathFileObject.java:102)
    at com.sun.tools.javac.file.JavacFileManager.getFileForOutput (JavacFileManager.java:938)
    at com.sun.tools.javac.file.JavacFileManager.getFileForOutput (JavacFileManager.java:900)
    at javax.tools.JavaFileManager.getFileForOutputForOriginatingFiles (JavaFileManager.java:535)
    at com.sun.tools.javac.main.DelegatingJavaFileManager.getFileForOutputForOriginatingFiles (DelegatingJavaFileManager.java:139)
    at com.sun.tools.javac.processing.JavacFiler.createResource (JavacFiler.java:551)
    at org.springframework.modulith.apt.SpringModulithProcessor.init (SpringModulithProcessor.java:133)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$ProcessorState.<init> (JavacProcessingEnvironment.java:699)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredProcessors$ProcessorStateIterator.next (JavacProcessingEnvironment.java:826)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs (JavacProcessingEnvironment.java:922)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run (JavacProcessingEnvironment.java:1265)
    at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing (JavacProcessingEnvironment.java:1380)
    at com.sun.tools.javac.main.JavaCompiler.processAnnotations (JavaCompiler.java:1272)
    at com.sun.tools.javac.main.JavaCompiler.compile (JavaCompiler.java:946)
    at com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0 (JavacTaskImpl.java:104)
    at com.sun.tools.javac.api.JavacTaskImpl.invocationHelper (JavacTaskImpl.java:152)
    at com.sun.tools.javac.api.JavacTaskImpl.doCall (JavacTaskImpl.java:100)
    at com.sun.tools.javac.api.JavacTaskImpl.call (JavacTaskImpl.java:94)
    at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess (JavaxToolsCompiler.java:126)
    at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile (JavacCompiler.java:214)
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1226)
    at org.apache.maven.plugin.compiler.CompilerMojo.execute (CompilerMojo.java:225)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:103)
    at java.lang.reflect.Method.invoke (Method.java:580)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)

There is no issue when we build our project locally, using the same maven and Java version used on CI. The difference is the OS (macOS vs. Linux).

On the CI we are using the following:

Maven version: Apache Maven 3.9.10 (5f519b97e944483d878815739f519b2eade0a91d)
Maven home: /usr/share/maven
Java version: 21.0.7, vendor: Eclipse Adoptium, runtime: /opt/java/openjdk
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.0-1088-azure", arch: "amd64", family: "unix"

We have been able to fix it by adding the following configuration on our pom:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>${maven-compiler-plugin.version}</version>
    <configuration>
        <source>${java.version}</source>
        <target>${java.version}</target>
        <annotationProcessorPaths>
            <path>
                <groupId>org.springframework.modulith</groupId>
                <artifactId>spring-modulith-api</artifactId>
                <version>${spring-modulith-bom.version}</version>
            </path>
        </annotationProcessorPaths>
        <generatedSourcesDirectory>${project.build.directory}/generated-sources/annotations</generatedSourcesDirectory>
        <compilerArgs>
            <arg>-s</arg>
            <arg>${project.build.directory}/generated-sources/annotations</arg>
        </compilerArgs>
    </configuration>
</plugin>

Do you have any idea what's going on?

Thank you,
Andrea

[odrotbohm]

Any chance you bundle this up into a small reproducer? I assume the artifact you're referring to for the APT is spring-modulith-apt, not spring-modulith-api?

[AndreaScarselliAx]

Hi @odrotbohm ,

We are not sure how to reproduce it, in fact, we are not even able to reproduce it on our local machines, the problem is only happening on the pipeline. I think the problem is happening on spring-modulith-apt. The dependencies we have are:

            <dependency>
                <groupId>org.springframework.modulith</groupId>
                <artifactId>spring-modulith-bom</artifactId>
                <version>${spring-modulith-bom.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        <dependency>
            <groupId>org.springframework.modulith</groupId>
            <artifactId>spring-modulith-starter-core</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.modulith</groupId>
            <artifactId>spring-modulith-starter-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.modulith</groupId>
            <artifactId>spring-modulith-starter-test</artifactId>
            <scope>test</scope>
        </dependency>

[odrotbohm]

I suspect the following to happen. It looks like Linux JDKs do not support trying to create resources using paths that resolve into already existing directories. The documentation generation has started to create the application module metadata in META-INF/spring-modulith/application-modules.json since 1.4. That means the META-INF/spring-modulith directories are created. Alternatively, the creation of the document can be created through the AOT phase of the project build. A subsequent invocation of the APT will result in asking for the creation of a resource we already have a folder for.

I've tweaked the resource creation to rather point to a dummy resource, as we ultimately only want to inspect the path to it to determine whether we're used in a test execution. I've pushed a fix to the 1.4.x branch, too. Would you mind giving 1.4.2-SNAPSHOT a try?

[AndreaScarselliAx]

Hey @odrotbohm ,

I can confirm the changes included in the SNAPSHOT fix the issue for me. Thank you so much for your help, looking forward to a release! :-)

[odrotbohm]

Lovely! Thanks for the feedback.