-
Notifications
You must be signed in to change notification settings - Fork 0
Open questions
This page lists some issues or "TODO" not yet addressed.
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)?
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).
TODO:
- 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.classfiles.
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
Providersis not used anywhere, but has@Namedand@Providesannotations. Is it needed? - As of Java 17, calls to
Stream.collect(Collectors.toList())could be replaced byStream.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 aRunnableinstead?
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.