Hello Thorsten
Le 02/08/2023 à 11:47, Thorsten Heit a écrit :
I see your point, but we're not living in a fully modularized Java
world: If you insist on having a Jar reside on the module path only,
this prevents others from using it on applications that are not fully
modularized or that
Hi Martin,
Even if a library decide to do the duplication, it may still not work.
Starting with Java 9, a service provider can be instantiated by invoking
a public static method named "provider" in the provider declared in
"module-info.class". This is an alternative to invoking the default
Hello Garret
Le 01/08/2023 à 18:32, Garret Wilson a écrit :
On 7/26/2023 1:42 PM, Martin Desruisseaux wrote:
… If a dependency is on the classpath, then the dependency is loaded
as an unnamed module, its "module-info" file is ignored and the
services that it contains are not discovered.
Can
On 7/26/2023 1:42 PM, Martin Desruisseaux wrote:
… If a dependency is on the classpath, then the dependency is loaded
as an unnamed module, its "module-info" file is ignored and the
services that it contains are not discovered.
Can you elaborate on the last point a little more? I haven't
Hello again
I wrote a test case with a very small Maven project (only trivial code)
reproducing the problem and a README.md file explaining the problem. The
Maven behavior is then reproduced on the command-line, and the expected
behavior provided by a command-line too. Unless there is some
Hello
If I'm understanding right, Maven put a dependency on the module-path
instead of the class-path only if:
1. the dependency is modularized (contains a "module-info" file), and
2. the project using the dependency is itself modularized.
Condition #1 is fine, but #2 is problematic. If a
