-----Original Message-----
From: Martin Desruisseaux <martin.desruisse...@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-unsubscr...@maven.apache.org For additional
commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
