Le 2023-11-03 à 16 h 45, Romain Manni-Bucau a écrit :
The detail point you forget is that since this is a partial solution
either nobody cares of it today and it will not be adopted more than
today (more later on that) or it will break in the future
Is the proposal only partial because it does not address the
--add-exports, --add-opens, etc. options? If yes, I think we can handle
the latter in an orthogonal way (a proposal was posted in a previous
email). If no, what is the hole, if we accept that the change is not for
Maven 3, that transitive dependencies would work like today, that
putting a dependency on the module-path of a non-JPMS application such
as Spring is okay, and if the latter is not okay user would have control?
The thing is that projects also use modules (check out helidon,
junit5, https://github.com/sormuras/testing-in-the-modular-world for
trivial examples).
It is true that JPMS is possible for *some* Maven projects in current
situation. But not for all of them. In a previous email, I provided a
link to a small executable Maven and Gradle project demonstrating a case
where it does not work, unless we apply some workarounds. I mentioned in
previous emails that those workarounds are sometime easy, but may also
be difficult to apply. Those difficulties can be reduced by making
possible to override the current Maven's heuristic rules, which is
currently not possible as far as I can see.
The above "testing-in-the-modular-world" link shows another aspect of
the problem. For making possible to run JUnit, that project duplicates
the `src/main/java/module-info.java` file into `src/test/java/` with the
addition of "exports" statements that are wanted only at test time. Such
duplication is easy when the `module-info` is small. But it become an
inconsistency risk when the `module-info` is complex with lot of service
providers, exports/opens statements, etc. This situation can be improved
with the <add-exports> element that I proposed in a previous email. This
is another topic for another thread, but the point is that there is room
for improvements and there are proposals on the table that may well work.
This is why originally I said this is likely not trying to solve any
real issue which will end up in plugin configuration more than in the
core pom.
Why the <type> proposal would not resolve any real issue? I provided a
executable example of the module-path issue:
https://github.com/Geomatys/MavenModulepathBug
With Tamas's proposal, I could add <type>module</type> in the pom.xml
file of the "client" module and the problem demonstrated by this test
case would be solved.
What would be nice and smooth is a hybrid between type and scope - but
once again I strongly think type should stick to "how to read/map an
artifact"
Ah, if the debate is about whether <type> is the right element where to
specify the type of path, I leave that to you Maven experts. This
question may join Henning's email on October 30 about the semantic of
scope, type, classifier, variant, etc. being a bit mixed. The only thing
is that I believe it should be some element inside <dependency>, and
should be optional for allowing users to care about class-path versus
module-path only when necessary.
Martin
