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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
