On Mon, 18 Mar 2024 at 07:50, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Hi Martin, > > Since we'll go v4 and really change the impl I guess we can drop all the > compiler args from properties and the not relevant options.
It would be helpful if there was a migration page that explained to users how to handle settings that are no longer supported. This could be quoted in the relevant error message. > Ultimately the only options would be: > > * fork options > * compiler args > * log/outputs options > > Anything else brings confusion and prevents us to validate properly the > command before it is executed (as of today). > > +1 to not "preparePaths" and just let the compilation be native. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le lun. 18 mars 2024 à 00:31, Martin Desruisseaux < > martin.desruisse...@geomatys.com> a écrit : > > > Hello all > > > > I'm not yet ready to submit a pull request for the reworked > > maven-compiler-plugin, but I would like to report some details about > > changes that would come, if accepted. This work is for Maven 4 only, the > > plugin for Maven 3 will stay unaffected. > > > > As proposed on GitHub comment [1], I'm modifying the implementation for > > using the standard javax.tools.JavaCompiler interface instead of the > > Plexus compiler. That interface is part of standard JDK since Java 6. It > > seems that the Eclipse compiler provides also an implementation of that > > interface, so compiler independence should be preserved. Forked > > compilation is handled by a custom implementation of that interface. The > > javax.tools.JavaCompiler interface has some methods needed for Java > > modules, for which I saw no direct equivalence in Plexus API. The gap > > may grow larger if future Java versions bring more evolution to the > > compiler API. The standard interface also has a cache mechanism that may > > bring performance improvements (to be verified) when compiling more than > > one set of sources, e.g. for multi-versions. It also opens the door for > > handling source and classes that are not files, for example by doing > > everything in memory (I have no plan to use this features now, but it > > become a possibility for the future). > > > > 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. > > > > The set of plugin parameters is the same as before: no addition and no > > removal, but there is some deprecation. Of course, what to deprecate or > > not is open to discussion. In the current state of work, the following > > parameters are deprecated but are still working: > > > > * <compilerArgument> (a single String): already replaced by > > <compilerArgs> (a list of Strings) since Maven 3.1. > > * <annotationProcessorPaths>: replaced by ordinary dependencies with > > <type>proc</type>, a new artifact type introduced in Maven 4-alpha13. > > > > The following parameters are marked as deprecated for removal in the > > current state of work. They all became no-op in the new plugin: > > > > * <forceJavacCompilerUse>: the documentation is not really explicit, > > but it seems to be about forcing the use of java.lang.Compiler > > instead of javax.tools.JavaCompiler (it does not seem to be about > > the javac command). The java.lang.Compiler class was deprecated > > since Java 9 and no longer exists in Java 21. > > * <outputFileName>: bundling many class files into a single file can > > be considered as the task of separated plugins, for example the JAR > > plugin. Furthermore, this parameter does not fit well in the context > > of Module Source Hierarchy, because the output is not a single JAR. > > * <compilerReuseStrategy>: the way that the javax.tools.JavaCompiler > > API is designed, this parameter does not seem relevant to instances > > of that interface. The parameter may be partially relevant to some > > objects used by JavaCompiler, but not fully (e.g. the "reuseSame" > > parameter value stay inapplicable). I suggest to let those decisions > > as plugin implementation details. > > * <skipMultiThreadWarning>: deprecated as a consequence of > > <compilerReuseStrategy> deprecation. > > > > The following parameters had their default value modified: > > > > * <source> and <target>: removed the default value and added a Javadoc > > saying "As of Java 9, the --release option is preferred." Its > > default value (if any) has not yet been chosen. > > > > Finally, the CompilerMojo and TestCompilerMojo subclasses contained > > magic in their preparePaths(…) method for trying to setup automatically > > some values of --patch-module and --add-reads options. This was done for > > multi-versions and for tests compilation. This magic has been removed > > for now (I will see during the tests if we need to bring back some). To > > avoid black magic or make it more controllable is the whole purpose of > > this effort in improving JPMS support. > > > > I have not yet reached the point where tests can be done. This email is > > only for reporting progress, and see if there is discussion. > > > > Martin > > > > [1]https://github.com/apache/maven/pull/1401#issuecomment-1974810724 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
