-
Notifications
You must be signed in to change notification settings - Fork 0
Implementation changes
This page lists some noticeable implementation changes.
The major change is the replacement of Plexus compiler API by the standard javax.tools.JavaCompiler API introduced in Java 6.
This changes required an almost full rewrite of the compiler plugin.
Other Plexus dependencies such as StringUtils could also be removed because they now have replacements in the standard Java API.
The previous plugin tried to be clever by guessing where to put dependencies (class-path versus module-path)
using heuristic rules based on whether the plugin saw module-info files or automatic module names,
by intercepting and modifying the values of user-supplied --patch-module compiler arguments,
by adding --path-module and --add-reads <module>=ALL-UNNAMED arguments on its own initiative, etc.
The result was saved in a META-INF/jpms.args file added to the JAR file.
Those heuristics have been removed from the Maven 4 plugin,
as Maven 4 aims to give configuration control to the users.
The heuristic rules are replaced by:
- Use of artifact
<type>modular-jar</type>or<type>classpath-jar</type>for specfiying where to put a dependency. - (more to be listed)
The Plexus scranners used for include/exclude filters have been replaced by java.nio.file.PathMatcher.
The set of allowed syntax contains at least "glob" and "regex".
See FileSystem.getPathMatcher(String) Javadoc for a description of the "glob" syntax.
If no syntax is specified, then the default syntax is "glob" with the following modification:
- Unless escaped by
\, all occurrences of the/character are replaced by the platform-specific separator.
The list of files to process is built by applying the path matcher on each regular (non directory) files. The walk in file trees has the following characteristics:
- Symbolic links are followed.
- Hidden files and hidden directories are ignored.
The code for detecting which files to recompile has been rewritten. The previous code had an issue with list of files generated and compared in one case as absolute files, and in other case as relative files. Consequently, the plugin always considered that all files changed, which may explain the performance issue reported in MCOMPILER-209.
Note that when the useIncrementalCompilation parameter was set to false, the previous plugin was still checking timestamps,
so some form of incremental compilation was still applied.
TODO: change the implementation by storing the timestamp of each source files in the list of files
instead of comparing them with the timestamps of the .class files.
It would avoid the problem that <createMissingPackageInfoClass> tries to resolve.
Or at least, store a flag telling whether a .class file has been generated for each source file.
The way to handle compiler options has been modified.
Previously, the Maven plugin validated some options before to pass them to the compiler.
For example, if the <debuglevel> value contains anything else than lines, vars or source, the plugin raised an error.
The intend was to provide more informative message.
But in the javax.tools.JavaCompiler interface, there is an API telling us whether an option is supported.
Therefor, the new plugin version first asks to the compiler whether the option is supported,
and only if the compiler said "no", the validation is performed for producing the error message.
Consequently, if the compiler claims to support the -g:foo option,
then the plugin will no longer block the use of the foo value in <debuglevel> even if the plugin does not know that value.
In the <createMissingPackageInfoClass> is set to true, the previous plugin generated a package-info.class file using a byte code generator.
The new plugin does not use byte code generator anymore.
Instead, the -Xpkginfo:always compiler option is added if the compiler supports that extra option.
If the extra option is not supported, then a warning is logged and no option is added.