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

Reply via email to