Skip to content

Open questions

Martin Desruisseaux edited this page Apr 23, 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)?

Incremental build

TODO:

  • Changes in compiler options should cause a full rebuild.
  • The checks for modified source files should be transitive: files using a modified file should also be marked as modified.
  • Consider using JavaFileManager.getFileForOutput(…) instead of heuristic rules for determining the paths to .class files.
  • Consider adding a rebuildOnAdd value for the incrementalCompilation parameter.

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:

  • Class Providers is not used anywhere, but has @Named and @Provides annotations. Is it needed?
  • 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