Le ven. 3 nov. 2023 à 17:50, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> 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? > > No no, orthogonal likely not but we can postpone it for sure. > that putting a dependency on the module-path of a non-JPMS application such as Spring is okay Is not ok for me and is a big hidden bug of current guess logic when not disabled IMHO, we should drop all that guess code probably. Then question is how do you enable modules but this is not a question for your maven module but per plugin (jaxws plugin will not use the same modules than compiler nor javadoc for ex). This is where the type proposal is not granular enough to handle advanced cases we are talking about - others not caring at all about the diff. > > > 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. > +1 to do that, it is required in plugins anyway whatever we do to dependency model and, thinking out loud, can be sufficient for these cases too, no? > > 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. > Hmm, makes years now but thought it was possible to complement it rather than just override but ultimately this is a setup issue where you would rather use the nested test classes model you drop at packaging time, ie put all the code in src/main cause by design it is what you want, a single module where maven creates 2 modules per maven module, don't think we need to hack anything there, here again we should just align on java for these rare cases. > > > > 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 Not sure I understand the issue, you highlight a bug in exec maven plugin (classpath and module path configuration share a single toggle - and toString BTW) but ultimately you misconfigured the plugin too: <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>3.1.0</version> <configuration> <mainClass>${exec.mainClass}</mainClass> <executable>java</executable> <longModulepath>false</longModulepath> <arguments> <argument>--module-path</argument> <modulepath> <dependency>${project.groupId}:service</dependency> </modulepath> <argument>--class-path</argument> <classpath> <dependency>${project.groupId}:${project.artifactId}</dependency> </classpath> <argument>--add-modules</argument> <argument>ALL-MODULE-PATH</argument> <argument>${exec.mainClass}</argument> </arguments> </configuration> </plugin> should make it work, you can say you don't want to explicitly list all paths but dependency plugin also enables to filter artifacts so looks like it is really about getting split paths more easily than getting a global for the maven module configuration which will prevent you to configure accurately each plugin which is actually required for these advanced JPMS cases (jaxws is really a hurting case). > > > 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. > Hmm, not using exec plugin then cause here the problem is solved, buggy but solved. That said happy to review a PR making Classpath/Modulepath (<classpath/> and <modulepath/>) implementation more configurable (using patterns for dependencies, handling transitive ones and things like that, current impl didnt evolve very well). > > > > 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. > Agree, default should stay classpath and module path shouldn't be enabled until requested, creates too much weird behaviors IMHO. Kind of disagree it should be on dependency for the reason mentionned ^^. > > Martin > >
