Skip to content

Open questions

Jump to bottom
Martin Desruisseaux edited this page Aug 4, 2024 · 8 revisions

This page lists some issues or "TODO" not yet addressed.

Plugin parameters

Should fileExtensions be a glob pattern instead of only a list of file extensions? Or just should this parameter be deprecated (is it really needed)?

Byte code generation

Consider removing ByteCodeTransformer and all dependencies to org.objectweb.asm. Instead, log a warning if reproducible build is detected and Java version is older than 22. If ASM is needed in the future, we may use the class-file API instead (JEP 466).

Incremental build

The checks for modified source files should be transitive: files using a modified file should also be marked as modified.

Implementation

getMavenCompilerPluginVersion() currently fetches the information from the META-INF/maven/org.apache.maven.plugins/maven-compiler-plugin/pom.properties file. But it could fetch the same information from the Implementation-Version attribute in META-INF/MANIFEST.MF, which would be more standard.

Varias:

  • As of Java 17, calls to Stream.collect(Collectors.toList()) could be replaced by Stream.toList().
  • Revisit if we really want absolute paths: search all occurrences of toAbsolutePath().
  • MOJO contains only an execute() method with no return value and no checked exception. Why not a Runnable instead?

Caching

It may be advantageous to reuse StandardJavaFileManager for main compilation, test compilation and Javadoc, because that interface can manage a cache to JAR files. Currently the plugin uses that interface in a try ... finally block, because JavaFileManager needs to release resources after use. We may need a cache mechanism with the same safety level as try ... finally, but wider scope. An alternative would be to compile main, test and javadoc in the same MOJO.

Clone this wiki locally