Re: Notes on maven-compiler-plugin work

[Tamás Cservenák]

Howdy,

went through implementation changes page (1st email), and am totally
aligned with those changes!

Keep up the good work!
T

On Tue, Apr 16, 2024 at 4:51 PM Martin Desruisseaux <
martin.desruisse...@geomatys.com> wrote:

> Oups, sorry. The link should be
> https://github.com/Geomatys/maven-compiler-plugin/wiki
>
>
> Le 2024-04-16 à 16 h 50, Martin Desruisseaux a écrit :
>
> > Hello all
> >
> > Le 2024-03-18 à 09 h 20, sebb a écrit :
> >
> >> 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.
> >
> > I started a wiki page summarizing the changes (to be moved somewhere
> > else at the end, if proposed changes are accepted):
> >
> >
> https://github.com/Geomatys/maven-compiler-plugin/wiki/Implementation-changes
> >
> > I have not yet removed the deprecated parameters. I think we can leave
> > the decision at the end, it should be easy enough to remove them at
> > that time.
> >
> > Martin
> >
> >
>

Re: Notes on maven-compiler-plugin work

[Martin Desruisseaux]

Oups, sorry. The link should be 
https://github.com/Geomatys/maven-compiler-plugin/wiki



Le 2024-04-16 à 16 h 50, Martin Desruisseaux a écrit :


Hello all

Le 2024-03-18 à 09 h 20, sebb a écrit :

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.


I started a wiki page summarizing the changes (to be moved somewhere 
else at the end, if proposed changes are accepted):



https://github.com/Geomatys/maven-compiler-plugin/wiki/Implementation-changes

I have not yet removed the deprecated parameters. I think we can leave 
the decision at the end, it should be easy enough to remove them at 
that time.


    Martin

Re: Notes on maven-compiler-plugin work

[Martin Desruisseaux]

Hello all

Le 2024-03-18 à 09 h 20, sebb a écrit :

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.


I started a wiki page summarizing the changes (to be moved somewhere 
else at the end, if proposed changes are accepted):


   https://github.com/Geomatys/maven-compiler-plugin/wiki/Implementation-changes

I have not yet removed the deprecated parameters. I think we can leave 
the decision at the end, it should be easy enough to remove them at that 
time.


    Martin

Re: Notes on maven-compiler-plugin work

[sebb]

On Mon, 18 Mar 2024 at 07:50, Romain Manni-Bucau  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  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> 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  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  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:
> >
> >   *  (a single String): already replaced by
> >  (a list of Strings) since Maven 3.1.
> >   * : replaced by ordinary dependencies with
> > proc, 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:
> >
> >   * : 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.
> >   * : 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.
> >   * : 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.
> >  

Re: Notes on maven-compiler-plugin work

[Romain Manni-Bucau]

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.
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  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



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  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  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:
>
>   *  (a single String): already replaced by
>  (a list of Strings) since Maven 3.1.
>   * : replaced by ordinary dependencies with
> proc, 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:
>
>   * : 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.
>   * : 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.
>   * : 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.
>   * : deprecated as a consequence of
>  deprecation.
>
> The following parameters had their default value modified:
>
>   *  and : 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