You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Guillaume Nodet <gn...@apache.org> on 2024/10/23 14:12:17 UTC
[DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Following the beta-5 release, we're going to update a bunch of plugins
(help welcome to port a few core plugins).
In particular, I think the maven-compiler-plugin would benefit from a merge
of Martin Deruisseaux's work around JPMS [1]. This leverages the
javax.tools API directly, so will remove the plexus dependency and will
certainly lead to some disruption, but ... that's what betas are for.
So unless there's a strong objection, I think we should merge Martin's
work...
[1] https://github.com/Geomatys/maven-compiler-plugin
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Daniel Schmid <da...@wwwmaster.at>.
On 24.10.24 11:03, Martin Desruisseaux wrote:
> About not trying anymore to be clever regarding -source versus
> -release options, there is good chance that this issue is mot since
> Maven 4 requires Java 17 for execution. Therefore, users should not
> have reason to use -source anymore. The concern expressed by Jorge is
> that asking users to add empty <source/> and <target/> elements in the
> plugin configuration compromise usability. I agree, but adding those
> empty elements should be needed only if the user inherited those
> elements (non-empty) from a parent POM, so they need to override them.
> Whether it happens often or not is something that we could discover
> with the beta.
I think this may still be an issue for people using a toolchain to
compile it with an older Java version (e.g. people wanting to compile
something using Java 8). In these cases, --release may not be available
so they have to use --source and --target.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-24 à 08 h 20, Guillaume Nodet a écrit :
>
> Is there any technical reason why we could not port those ?
>
About MCOMPILER-542 (a workaround that modified the module-info.class
generated by javac versions before Java 22), there is no technical
reason apart a desire to reduce dependencies and to avoid transforming
compiler outputs without user's acknowledgement (I was surprised to
discover that Maven rewrites some class files generated by javac).
Especially since previously, Maven modified the module-info.class files
only if reproducible built was enabled. But now that reproducible build
is enabled by default, Maven will modify the module-info.class
practically always when compiling with a JDK prior to Java 22. I don't
know if all users are comfortable with that. If no concern are
expressed, I can put MCOMPILER-542 back this weekend.
About not trying anymore to be clever regarding -source versus -release
options, there is good chance that this issue is mot since Maven 4
requires Java 17 for execution. Therefore, users should not have reason
to use -source anymore. The concern expressed by Jorge is that asking
users to add empty <source/> and <target/> elements in the plugin
configuration compromise usability. I agree, but adding those empty
elements should be needed only if the user inherited those elements
(non-empty) from a parent POM, so they need to override them. Whether it
happens often or not is something that we could discover with the beta.
Generally, the rewritten plugin has a policy of not overwriting Java
defaults with Maven's own opinion of what the default should have been.
A goal is to make Maven more easily predictable for peoples who are
familiar with javac options. But this is part of the things that can be
revisited according user's feedback.
Martin
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Guillaume Nodet <gn...@apache.org>.
Is there any technical reason why we could not port those ?
Le mer. 23 oct. 2024 à 22:46, Jorge Solórzano <jo...@gmail.com> a écrit :
> Without delving into every detail, one concern I have is the inability to
> use the <release> option alongside <source> and <target>, MCOMPILER-582
> <https://issues.apache.org/jira/browse/MCOMPILER-582> was a nice
> improvement, but I'm not sure if that behavior remains. In any case, in my
> opinion, relying on an empty <source/> <target/> workaround isn't ideal, as
> it compromises usability.
>
> Another point worth mentioning is MCOMPILER-542
> <https://issues.apache.org/jira/browse/MCOMPILER-542>. While I understand
> the goal of dropping dependencies, the regression it introduces for
> reproducible builds in modular projects is concerning. The recommended
> workaround of compiling with Java 22 or later isn’t practical for every
> project, especially considering that not all projects are ready to adopt
> Java 22, and as Hervé pointed out, even though JDK 22 contains the fix, the
> general expectation is that Reproducible Builds releases will be based on
> the next LTS version. Relying on a non-LTS compiler to build releases for
> Maven Central doesn't align with best practices.
>
> While I appreciate the modernization efforts for the maven-compiler-plugin,
> we need to balance this with user experience considerations. Removing
> features without addressing these concerns could detract from the overall
> usability of the plugin. I understand this can be part of an incremental
> effort, but ensuring a smooth UX is crucial to avoid user frustration over
> seemingly small issues.
>
> +0 (nb)
>
> On Wed, Oct 23, 2024 at 4:40 PM Martin Desruisseaux <
> martin.desruisseaux@geomatys.com> wrote:
>
> > Le 2024-10-23 à 16 h 22, Ralph Goers a écrit :
> >
> > > What is the easiest way to determine what has been changed? When I was
> > > working on Log4j’s JPMS support Maven’s handling of JPMS frequently
> > > caused problems and forced us to do some things I consider kind of
> ugly.
> > >
> > The main changes are described there, especially the 2 first points
> > ("Incompatible changes" and "Changes in compiler parameters"). The rest
> > can easily be ignored:
> >
> > https://github.com/Geomatys/maven-compiler-plugin/wiki
> >
> > If accepted, above-cited two points would be ported to the APT format
> > for the plugin site.
> >
> > If anything break e.g. with Log4J, we will either fix the regression or
> > document the changes with proposed alternatives. But it implies that
> > there is a risk that the compiler plugin 4.0.0-beta-2 breaks some builds
> > and that we need a couple of beta releases before to resolve the issues.
> >
> > Martin
> >
> >
>
--
------------------------
Guillaume Nodet
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Jorge Solórzano <jo...@gmail.com>.
Without delving into every detail, one concern I have is the inability to
use the <release> option alongside <source> and <target>, MCOMPILER-582
<https://issues.apache.org/jira/browse/MCOMPILER-582> was a nice
improvement, but I'm not sure if that behavior remains. In any case, in my
opinion, relying on an empty <source/> <target/> workaround isn't ideal, as
it compromises usability.
Another point worth mentioning is MCOMPILER-542
<https://issues.apache.org/jira/browse/MCOMPILER-542>. While I understand
the goal of dropping dependencies, the regression it introduces for
reproducible builds in modular projects is concerning. The recommended
workaround of compiling with Java 22 or later isn’t practical for every
project, especially considering that not all projects are ready to adopt
Java 22, and as Hervé pointed out, even though JDK 22 contains the fix, the
general expectation is that Reproducible Builds releases will be based on
the next LTS version. Relying on a non-LTS compiler to build releases for
Maven Central doesn't align with best practices.
While I appreciate the modernization efforts for the maven-compiler-plugin,
we need to balance this with user experience considerations. Removing
features without addressing these concerns could detract from the overall
usability of the plugin. I understand this can be part of an incremental
effort, but ensuring a smooth UX is crucial to avoid user frustration over
seemingly small issues.
+0 (nb)
On Wed, Oct 23, 2024 at 4:40 PM Martin Desruisseaux <
martin.desruisseaux@geomatys.com> wrote:
> Le 2024-10-23 à 16 h 22, Ralph Goers a écrit :
>
> > What is the easiest way to determine what has been changed? When I was
> > working on Log4j’s JPMS support Maven’s handling of JPMS frequently
> > caused problems and forced us to do some things I consider kind of ugly.
> >
> The main changes are described there, especially the 2 first points
> ("Incompatible changes" and "Changes in compiler parameters"). The rest
> can easily be ignored:
>
> https://github.com/Geomatys/maven-compiler-plugin/wiki
>
> If accepted, above-cited two points would be ported to the APT format
> for the plugin site.
>
> If anything break e.g. with Log4J, we will either fix the regression or
> document the changes with proposed alternatives. But it implies that
> there is a risk that the compiler plugin 4.0.0-beta-2 breaks some builds
> and that we need a couple of beta releases before to resolve the issues.
>
> Martin
>
>
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-24 à 14 h 25, Robert Scholte a écrit :
> Just one question: what will happen with Maven3 users (or any other
> tool) if one of their dependencies has this special type?
Rephrasing as "what will happen with a Maven 3 plugin running on Maven 4
without having been updated to the Maven 4 API?", the Java methods
which, in Maven 3, were returning the list of all JAR dependencies
continue to return all JARs in Maven 4, regardless if they are "jar",
"modular-jar" or "classpath-jar". If those plugins were applying their
own heuristic rules for deciding what to put on the classpath or
module-path, it should continue to work, at the risk of being
inconsistent with user's desire. In order to distinguish between "jar",
"modular-jar" or "classpath-jar" (otherwise than by invoking
Artifact.getType() method), the plugin needs to invoke new Maven 4 API.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Tamás Cservenák <ta...@cservenak.net>.
We are talking about Maven 4 plugins (the compiler, for example), so
we are talking about model version 4.1.0+ strictly here.
No Maven3 involved (or model version 4.0.0). It is in that long thread
clarified, that due shortcomings of Maven3 internals, it cannot be
done (without breaking all of it).
Thanks
T
On Thu, Oct 24, 2024 at 2:27 PM Robert Scholte <rf...@apache.org> wrote:
>
> Thanks, that's indeed long.
>
> But seeing the result makes we wonder if the right decision has been made with regard to pom consumption.
> To me this looks like this is going to disrupt the java ecosystem.
> Just one question: what will happen with Maven3 users (or any other tool) if one of their dependencies has this special type?
> Not sure why this had to be forced into the current modelVersion 4.0.0 like this.
>
> Anyway, I guess the decision has been made.
> Robert
>
> -----Original Message-----
> From: Tamás Cservenák <ta...@cservenak.net>
> Sent: donderdag 24 oktober 2024 14:01
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
>
> Robert,
>
> you might missed this quite long thread that happened about a year ago:
> https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn
>
> Just to get into the picture, and not repeat the whole story again :)
>
> Thanks
> T
>
> On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte <rf...@apache.org> wrote:
> >
> > Inline responses...
> >
> > -----Original Message-----
> > From: Martin Desruisseaux <ma...@geomatys.com>
> > Sent: donderdag 24 oktober 2024 12:38
> > To: dev@maven.apache.org
> > Subject: Re: [DISCUSS] Merge JPMS work in upcoming
> > maven-compiler-plugin beta-2
> >
> > Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
> > >
> > > Can you explain the problem you're trying to solve? In particular I
> > > don't understand the need for modular-jar and classpath-jar, as
> > > currently both classpath and modulepath are already build up
> > > correctly based on the module descriptors.
> > >
> > The problem is that they are not always build up correctly. Maven uses heuristic rules, and there is currently no easy way a user could change Maven's mind when those rules do not match user's intend. Examples:
> >
> > * A user may want to put non-modular JAR files on the module path.
> > This is called automatic modules. I'm aware that there are arguments
> > about whether this is good practice or not, but the new compiler
> > plugin is not taking position in that debate. Automatic modules are
> > officially supported and part of the Java specification, and there
> > are sometime legitimate reasons to want to use them.
> >
> > >> What is effectively the difference here? As long as there's no reference from a module descriptor to a module (either named or automatic) there should be no difference.
> > >> It is already possible to refer to automatic modules, including a
> > >> big disclaimer in case it is a library (automatic modules are less problematic for applications) Do you have a minimized project that demonstrates that there are different results?
> >
> > * Maven currently puts everything on the class-path when a project is
> > non-modular. But a non-modular project may still want to put its
> > modular dependencies on the module-path. This choice changes the way
> > that services are loaded for example.
> >
> > >> Loading services sounds like a runtime issue, not a compile time issue.
> > >> Do you have a minimized project that demonstrates that there are different results?
> >
> > So what Maven is currently doing is not always the right thing to do. It may be a reasonable default however. Therefore, the "jar" type will continue to behave as today. But the "classpath-jar" and "modular-jar"
> > types, or something equivalent, are needed when the Maven's heuristic rules don't do what the user wants.
> >
> > >> I think that the type is abused here. Also, does this mean that other tools suddenly need to understand this type as well? Or does Maven4 revert it back to "jar" in the consumer-pom, in which case you will have different behavior at runtime?
> > >> In both cases there's an issue.
> > >> If there really is an issue, there should be a solution that doesn't impact any other pom-consumer, it should be scoped to maven-build section.
> >
> >
> > Martin
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > additional commands, e-mail: dev-help@maven.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Robert Scholte <rf...@apache.org>.
Thanks, that's indeed long.
But seeing the result makes we wonder if the right decision has been made with regard to pom consumption.
To me this looks like this is going to disrupt the java ecosystem.
Just one question: what will happen with Maven3 users (or any other tool) if one of their dependencies has this special type?
Not sure why this had to be forced into the current modelVersion 4.0.0 like this.
Anyway, I guess the decision has been made.
Robert
-----Original Message-----
From: Tamás Cservenák <ta...@cservenak.net>
Sent: donderdag 24 oktober 2024 14:01
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Robert,
you might missed this quite long thread that happened about a year ago:
https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn
Just to get into the picture, and not repeat the whole story again :)
Thanks
T
On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte <rf...@apache.org> wrote:
>
> Inline responses...
>
> -----Original Message-----
> From: Martin Desruisseaux <ma...@geomatys.com>
> Sent: donderdag 24 oktober 2024 12:38
> To: dev@maven.apache.org
> Subject: Re: [DISCUSS] Merge JPMS work in upcoming
> maven-compiler-plugin beta-2
>
> Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
> >
> > Can you explain the problem you're trying to solve? In particular I
> > don't understand the need for modular-jar and classpath-jar, as
> > currently both classpath and modulepath are already build up
> > correctly based on the module descriptors.
> >
> The problem is that they are not always build up correctly. Maven uses heuristic rules, and there is currently no easy way a user could change Maven's mind when those rules do not match user's intend. Examples:
>
> * A user may want to put non-modular JAR files on the module path.
> This is called automatic modules. I'm aware that there are arguments
> about whether this is good practice or not, but the new compiler
> plugin is not taking position in that debate. Automatic modules are
> officially supported and part of the Java specification, and there
> are sometime legitimate reasons to want to use them.
>
> >> What is effectively the difference here? As long as there's no reference from a module descriptor to a module (either named or automatic) there should be no difference.
> >> It is already possible to refer to automatic modules, including a
> >> big disclaimer in case it is a library (automatic modules are less problematic for applications) Do you have a minimized project that demonstrates that there are different results?
>
> * Maven currently puts everything on the class-path when a project is
> non-modular. But a non-modular project may still want to put its
> modular dependencies on the module-path. This choice changes the way
> that services are loaded for example.
>
> >> Loading services sounds like a runtime issue, not a compile time issue.
> >> Do you have a minimized project that demonstrates that there are different results?
>
> So what Maven is currently doing is not always the right thing to do. It may be a reasonable default however. Therefore, the "jar" type will continue to behave as today. But the "classpath-jar" and "modular-jar"
> types, or something equivalent, are needed when the Maven's heuristic rules don't do what the user wants.
>
> >> I think that the type is abused here. Also, does this mean that other tools suddenly need to understand this type as well? Or does Maven4 revert it back to "jar" in the consumer-pom, in which case you will have different behavior at runtime?
> >> In both cases there's an issue.
> >> If there really is an issue, there should be a solution that doesn't impact any other pom-consumer, it should be scoped to maven-build section.
>
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Tamás Cservenák <ta...@cservenak.net>.
Robert,
you might missed this quite long thread that happened about a year ago:
https://lists.apache.org/thread/x99pj75vfn5p3xtr0mvhgs5s4935j3gn
Just to get into the picture, and not repeat the whole story again :)
Thanks
T
On Thu, Oct 24, 2024 at 1:18 PM Robert Scholte <rf...@apache.org> wrote:
>
> Inline responses...
>
> -----Original Message-----
> From: Martin Desruisseaux <ma...@geomatys.com>
> Sent: donderdag 24 oktober 2024 12:38
> To: dev@maven.apache.org
> Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
>
> Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
> >
> > Can you explain the problem you're trying to solve? In particular I
> > don't understand the need for modular-jar and classpath-jar, as
> > currently both classpath and modulepath are already build up correctly
> > based on the module descriptors.
> >
> The problem is that they are not always build up correctly. Maven uses heuristic rules, and there is currently no easy way a user could change Maven's mind when those rules do not match user's intend. Examples:
>
> * A user may want to put non-modular JAR files on the module path.
> This is called automatic modules. I'm aware that there are arguments
> about whether this is good practice or not, but the new compiler
> plugin is not taking position in that debate. Automatic modules are
> officially supported and part of the Java specification, and there
> are sometime legitimate reasons to want to use them.
>
> >> What is effectively the difference here? As long as there's no reference from a module descriptor to a module (either named or automatic) there should be no difference.
> >> It is already possible to refer to automatic modules, including a big disclaimer in case it is a library (automatic modules are less problematic for applications)
> >> Do you have a minimized project that demonstrates that there are different results?
>
> * Maven currently puts everything on the class-path when a project is
> non-modular. But a non-modular project may still want to put its
> modular dependencies on the module-path. This choice changes the way
> that services are loaded for example.
>
> >> Loading services sounds like a runtime issue, not a compile time issue.
> >> Do you have a minimized project that demonstrates that there are different results?
>
> So what Maven is currently doing is not always the right thing to do. It may be a reasonable default however. Therefore, the "jar" type will continue to behave as today. But the "classpath-jar" and "modular-jar"
> types, or something equivalent, are needed when the Maven's heuristic rules don't do what the user wants.
>
> >> I think that the type is abused here. Also, does this mean that other tools suddenly need to understand this type as well? Or does Maven4 revert it back to "jar" in the consumer-pom, in which case you will have different behavior at runtime?
> >> In both cases there's an issue.
> >> If there really is an issue, there should be a solution that doesn't impact any other pom-consumer, it should be scoped to maven-build section.
>
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-24 à 14 h 13, Robert Scholte a écrit :
> What I'm seeing here is: service provides both a module descriptor
> with the services, so it can be used on the modulepath At the same
> time it also provides a META-INF/services to make it compatible for
> the classpath as well. This is awesome to make it work for both
> classpath and modulepath But there's one important thing here: this
> only makes sense if both are the same. (I can't think of a reason to
> do it other like this, other than demonstrating where the service is
> coming from)
The two approaches (module-info versus META-INF) are not strictly
equivalent. For example, the static 'provider()' method works only with
module-info and doesn't work with META-INF. Workarounds are possible,
but can be tedious especially when the instance returned by 'provider()'
may implement different interfaces depending on runtime environment. In
order to avoid above-cited difficulty, or in order to avoid the risk of
inconsistency between module-info and META-INF (e.g. updating the former
and forgetting the update the latter), an implementation may decide to
drop META-INF. This is equivalent to dropping the possibility to run the
library on the class-path. We may argue about whether this is good
practice or not, but for the purpose of this discussion, the key point
is that users can be stuck if they cannot take control on what is on the
class-path versus module-path.
> Even though Maven introduced the pom.xml, we should really prevent
> making behaviour changes for modelVersion 4.0.0 as being uploaded to
> Maven Central.
My understanding is that there is an agreement on that. It has been
proposed (independently of the JPMS work) to have a decoupling between
the POM used for building the project, and the POM deployed on Maven
Central. The former may evolve, but the latter would stay the same.
Except I guess for the new types, but this evolution doesn't add new XML
elements in the model.
> In this case the type is being abused for deciding where the jars
> should be used. If this needs to be explicitly done, it should be some
> sort of subscope of compile (which doesn't exist).
The location (class-path versus module-path) needs to be the same (at
least by default) for compiler, javadoc, surefire, exec, etc. So it is a
wider concept than a compiler scope.
> Don't turn a runtime issue (where the application needs to choose
> providers for servers) into a generic compile+runtime issue.
I'm not sure to understand this argument... Class-path versus
module-path is indeed a compile + runtime + javadoc + other JDK tools issue.
> Regarding annotations and doclets, these should be dependencies of
> that plugin with a scope, as they are not project dependencies. (I
> think I've created an issue for it, probably targeted for M5)
This is indeed one possible way to see those dependencies. But that
would not resolve fully the problem. For example, we would still need to
distinguish whether a Javadoc plugin dependency shall be put on the
doclet path or the taglet path. Since we already need to do this kind of
distinction for class-path versus module-path, the same mechanism can be
generalized to doclet versus taglet paths, and all other paths.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Robert Scholte <rf...@apache.org>.
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.com>
Sent: donderdag 24 oktober 2024 13:38
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :
(about automatic modules)
> What is effectively the difference here? As long as there's no
> reference from a module descriptor to a module (either named or
> automatic) there should be no difference.
>
The purpose of automatic modules is to allow them to be referenced from the module descriptor. But it doesn't work if the automatic module is not on the module path.
> Do you have a minimized project that demonstrates that there are
> different results?
>
I need to check if there is one specifically for the above (will do that after lunch), but some issues are demonstrated there:
https://github.com/Geomatys/MavenModulepathBug
>>What I'm seeing here is: service provides both a module descriptor with the services, so it can be used on the modulepath
>>At the same time it also provides a META-INF/services to make it compatible for the classpath as well.
>>This is awesome to make it work for both classpath and modulepath
>>But there's one important thing here: this only makes sense if both are the same.
>>(I can't think of a reason to do it other like this, other than demonstrating where the service is coming from)
> I think that the type is abused here. Also, does this mean that other
> tools suddenly need to understand this type as well? Or does Maven4
> revert it back to "jar" in the consumer-pom, in which case you will
> have different behavior at runtime?
> In both cases there's an issue. If there really is an issue, there
> should be a solution that doesn't impact any other pom-consumer, it
> should be scoped to maven-build section.
Other tools will need to be updated. This is the updated mentioned in previous email concerning the javadoc and surefire plugin. But we don't have much choice. I don't see how we could resolve class-path versus module-path issue without some new API. Furthermore, this change has been opportunistically generalized to other kind of path issue. The type also allow to specify whether to put a dependency on the doclet path, taglet path, annotation processor path, etc. Thus, providing a unified way to manage various kind of paths instead of heterogeneous plugin configurations that mimic the dependencies section.
Martin
>> Even though Maven introduced the pom.xml, we should really prevent making behaviour changes for modelVersion 4.0.0 as being uploaded to Maven Central.
>> In this case the type is being abused for deciding where the jars should be used. If this needs to be explicitly done, it should be some sort of subscope of compile (which doesn't exist).
>> Don't turn a runtime issue (where the application needs to choose providers for servers) into a generic compile+runtime issue.
>> Regarding annotations and doclets, these should be dependencies of that plugin with a scope, as they are not project dependencies. (I think I've created an issue for it, probably targeted for M5)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-24 à 13 h 17, Robert Scholte a écrit :
(about automatic modules)
> What is effectively the difference here? As long as there's no
> reference from a module descriptor to a module (either named or
> automatic) there should be no difference.
>
The purpose of automatic modules is to allow them to be referenced from
the module descriptor. But it doesn't work if the automatic module is
not on the module path.
> Do you have a minimized project that demonstrates that there are
> different results?
>
I need to check if there is one specifically for the above (will do that
after lunch), but some issues are demonstrated there:
https://github.com/Geomatys/MavenModulepathBug
> I think that the type is abused here. Also, does this mean that other
> tools suddenly need to understand this type as well? Or does Maven4
> revert it back to "jar" in the consumer-pom, in which case you will
> have different behavior at runtime?
> In both cases there's an issue. If there really is an issue, there
> should be a solution that doesn't impact any other pom-consumer, it
> should be scoped to maven-build section.
Other tools will need to be updated. This is the updated mentioned in
previous email concerning the javadoc and surefire plugin. But we don't
have much choice. I don't see how we could resolve class-path versus
module-path issue without some new API. Furthermore, this change has
been opportunistically generalized to other kind of path issue. The type
also allow to specify whether to put a dependency on the doclet path,
taglet path, annotation processor path, etc. Thus, providing a unified
way to manage various kind of paths instead of heterogeneous plugin
configurations that mimic the dependencies section.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Robert Scholte <rf...@apache.org>.
Inline responses...
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.com>
Sent: donderdag 24 oktober 2024 12:38
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
>
> Can you explain the problem you're trying to solve? In particular I
> don't understand the need for modular-jar and classpath-jar, as
> currently both classpath and modulepath are already build up correctly
> based on the module descriptors.
>
The problem is that they are not always build up correctly. Maven uses heuristic rules, and there is currently no easy way a user could change Maven's mind when those rules do not match user's intend. Examples:
* A user may want to put non-modular JAR files on the module path.
This is called automatic modules. I'm aware that there are arguments
about whether this is good practice or not, but the new compiler
plugin is not taking position in that debate. Automatic modules are
officially supported and part of the Java specification, and there
are sometime legitimate reasons to want to use them.
>> What is effectively the difference here? As long as there's no reference from a module descriptor to a module (either named or automatic) there should be no difference.
>> It is already possible to refer to automatic modules, including a big disclaimer in case it is a library (automatic modules are less problematic for applications)
>> Do you have a minimized project that demonstrates that there are different results?
* Maven currently puts everything on the class-path when a project is
non-modular. But a non-modular project may still want to put its
modular dependencies on the module-path. This choice changes the way
that services are loaded for example.
>> Loading services sounds like a runtime issue, not a compile time issue.
>> Do you have a minimized project that demonstrates that there are different results?
So what Maven is currently doing is not always the right thing to do. It may be a reasonable default however. Therefore, the "jar" type will continue to behave as today. But the "classpath-jar" and "modular-jar"
types, or something equivalent, are needed when the Maven's heuristic rules don't do what the user wants.
>> I think that the type is abused here. Also, does this mean that other tools suddenly need to understand this type as well? Or does Maven4 revert it back to "jar" in the consumer-pom, in which case you will have different behavior at runtime?
>> In both cases there's an issue.
>> If there really is an issue, there should be a solution that doesn't impact any other pom-consumer, it should be scoped to maven-build section.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-24 à 12 h 07, Robert Scholte a écrit :
>
> Can you explain the problem you're trying to solve? In particular I
> don't understand the need for modular-jar and classpath-jar, as
> currently both classpath and modulepath are already build up correctly
> based on the module descriptors.
>
The problem is that they are not always build up correctly. Maven uses
heuristic rules, and there is currently no easy way a user could change
Maven's mind when those rules do not match user's intend. Examples:
* A user may want to put non-modular JAR files on the module path.
This is called automatic modules. I'm aware that there are arguments
about whether this is good practice or not, but the new compiler
plugin is not taking position in that debate. Automatic modules are
officially supported and part of the Java specification, and there
are sometime legitimate reasons to want to use them.
* Maven currently puts everything on the class-path when a project is
non-modular. But a non-modular project may still want to put its
modular dependencies on the module-path. This choice changes the way
that services are loaded for example.
So what Maven is currently doing is not always the right thing to do. It
may be a reasonable default however. Therefore, the "jar" type will
continue to behave as today. But the "classpath-jar" and "modular-jar"
types, or something equivalent, are needed when the Maven's heuristic
rules don't do what the user wants.
Martin
RE: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Robert Scholte <rf...@apache.org>.
Can you explain the problem you're trying to solve?
In particular I don't understand the need for modular-jar and classpath-jar, as currently both classpath and modulepath are already build up correctly based on the module descriptors.
Thanks,
Robert
-----Original Message-----
From: Martin Desruisseaux <ma...@geomatys.com>
Sent: woensdag 23 oktober 2024 16:40
To: dev@maven.apache.org
Subject: Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Le 2024-10-23 à 16 h 22, Ralph Goers a écrit :
> What is the easiest way to determine what has been changed? When I was
> working on Log4j’s JPMS support Maven’s handling of JPMS frequently
> caused problems and forced us to do some things I consider kind of ugly.
>
The main changes are described there, especially the 2 first points ("Incompatible changes" and "Changes in compiler parameters"). The rest can easily be ignored:
https://github.com/Geomatys/maven-compiler-plugin/wiki
If accepted, above-cited two points would be ported to the APT format for the plugin site.
If anything break e.g. with Log4J, we will either fix the regression or document the changes with proposed alternatives. But it implies that there is a risk that the compiler plugin 4.0.0-beta-2 breaks some builds and that we need a couple of beta releases before to resolve the issues.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-23 à 16 h 22, Ralph Goers a écrit :
> What is the easiest way to determine what has been changed? When I was
> working on Log4j’s JPMS support Maven’s handling of JPMS frequently
> caused problems and forced us to do some things I consider kind of ugly.
>
The main changes are described there, especially the 2 first points
("Incompatible changes" and "Changes in compiler parameters"). The rest
can easily be ignored:
https://github.com/Geomatys/maven-compiler-plugin/wiki
If accepted, above-cited two points would be ported to the APT format
for the plugin site.
If anything break e.g. with Log4J, we will either fix the regression or
document the changes with proposed alternatives. But it implies that
there is a risk that the compiler plugin 4.0.0-beta-2 breaks some builds
and that we need a couple of beta releases before to resolve the issues.
Martin
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-10-24 à 07 h 57, Olivier Lamy a écrit :
>
> I wonder if the changes have been ported to surefire and javadoc?
>
Not yet, but indeed those plugins will also need to be updated. We may
not be able to update them in same time as the compiler plugin. A
consequence is that some tasks that should become easier with the new
compiler plugin (e.g. control on class-path versus module-path) but will
stay difficult with the surefire and javadoc plugins. However, I don't
think that they would be more difficult than they currently are.
We could do compiler, surefire, javadoc and jar (that latter may also
need an update) in parallel. My current way of working is rather to
focus on one plugin at a time, and to finish the compiler plugin before
to move on to the next plugin (the next work item is the way to declare
sources). But this approach may be changed if it appears necessary.
Martin
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Olivier Lamy <ol...@apache.org>.
I wonder if the changes have been ported to surefire and javadoc?
Or maybe not needed as no impact? Sorry just a question from the
peanut gallery (as I didn't have a look at the changes).
But I remember suffering (because I was more involved at this time) a
lot of issues in the past when JPMS was included as part the tooling
via plexus-java and most of the plugins were not in sync regarding
JPMS .
Some weird (bad) workaround were needed to make all those plugins
working together with JPMS.
On Thu, 24 Oct 2024 at 00:22, Ralph Goers <ra...@dslextreme.com> wrote:
>
> What is the easiest way to determine what has been changed? When I was working on Log4j’s JPMS support Maven’s handling of JPMS frequently caused problems and forced us to do some things I consider kind of ugly.
>
> Ralph
>
> > On Oct 23, 2024, at 7:12 AM, Guillaume Nodet <gn...@apache.org> wrote:
> >
> > Following the beta-5 release, we're going to update a bunch of plugins
> > (help welcome to port a few core plugins).
> > In particular, I think the maven-compiler-plugin would benefit from a merge
> > of Martin Deruisseaux's work around JPMS [1]. This leverages the
> > javax.tools API directly, so will remove the plexus dependency and will
> > certainly lead to some disruption, but ... that's what betas are for.
> >
> > So unless there's a strong objection, I think we should merge Martin's
> > work...
> >
> > [1] https://github.com/Geomatys/maven-compiler-plugin
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Ralph Goers <ra...@dslextreme.com>.
What is the easiest way to determine what has been changed? When I was working on Log4j’s JPMS support Maven’s handling of JPMS frequently caused problems and forced us to do some things I consider kind of ugly.
Ralph
> On Oct 23, 2024, at 7:12 AM, Guillaume Nodet <gn...@apache.org> wrote:
>
> Following the beta-5 release, we're going to update a bunch of plugins
> (help welcome to port a few core plugins).
> In particular, I think the maven-compiler-plugin would benefit from a merge
> of Martin Deruisseaux's work around JPMS [1]. This leverages the
> javax.tools API directly, so will remove the plexus dependency and will
> certainly lead to some disruption, but ... that's what betas are for.
>
> So unless there's a strong objection, I think we should merge Martin's
> work...
>
> [1] https://github.com/Geomatys/maven-compiler-plugin
>
>
> --
> ------------------------
> Guillaume Nodet
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] Merge JPMS work in upcoming maven-compiler-plugin beta-2
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Hello all
The proposed new compiler plugin has been updated with the following
changes:
* Use of ASM for rewriting the module-info.java file on JDK older than
22 has been reintroduced (for reproductible builds).
* Support for overwriting module-info.java in the tests has been
reimplemented, but in a way quite different than Maven 3. See [1].
The attempt to be clever regarding --source versus --release options has
not been reintroduced yet, but would be easy to do if it appears
desirable. Before to do so, I would be curious to see if collisions
between those two options happen often, and if so, if they appear in
places that we can adjust (e.g. in an inherited POM). If it appears that
Maven 3 behavior should be kept, maybe it would be worth to start a
discussion about whether to introduce a "compatibility mode"?
We have one test failure, but I'm not sure that it come from the
compiler. It seems to come from Maven core. If anyone has some clue
about [2], it would be appreciated.
Martin
[1]https://github.com/Geomatys/maven-compiler-plugin/wiki/Implementation-changes#overwriting-module-info-in-tests
[2]https://github.com/apache/maven-compiler-plugin/pull/269#issuecomment-2441456531