Le ven. 3 nov. 2023 à 20:55, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2023-11-03 à 19 h 33, Romain Manni-Bucau a écrit : > > >> 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. > > > The current guess code in Maven 3 puts the dependency on the class-path, > which in my understanding is the behaviour that you want. The <type> > proposal would put the dependency on whatever path the <type> said it > should be. If the user is not okay with that, (s)he can override in the > same way that (s)he can override the version of transitive dependencies. > Means you create as much type as plugin*pathTypePerPlugin, looks overkill. And just using class/module paths does not work, so ultimately plugins will need filters and maybe just rely on scopes+filters - still trying to find a solution making eveyone happy. > A dependency may be designed for working only on the module path (it is > developer's choice as any other software requirement, such as the > minimal Java version), which is why I think that by default, dependency > should go where the library producer said that it should go. But again, > users can override if they want. > > > > 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 > > > Are you referring to the --add-modules or --limit-modules options of > Java? If so, I think that they are compatible with the <type> proposal > and can be discussed in a next step. The first step that we are trying > to resolve now is to build the module-path. Next, it is indeed possible > to tell Java to "see" only a subset of the modules available on the > module-path. I think that this option is more typically used when the > module-path is a whole directory instead than an enumeration of > dependencies as Maven does. If users nevertheless want to use the > --add-modules or --limit-modules options, maybe they could be options of > the exec plugin. Those options are not paths, only comma-separated lists > of modules names. > Yes, but you just added a jaxws type to maven core - see why this does not scale/work? Just means we cant get external plugins anymore or we will duplicate a lot deps (same gav different type...please no). > > > (…snip…) 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 > > > I'm not sure if you are talking about the Java compiler's "Module Source > Hierarchy" here. If yes, this is indeed something that I would like, but > I'm not trying to push that for Maven (I presume that it would be a too > big change). My hope for Maven has smaller scope: module-path and making > easier to setup the --add-exports and --add-opens options. > This already works with maven, needs to tune the folder layouts and a few plugins - and to be honest I hope it never becomes the default, so not sure what misses there. > > 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: > > > Thanks for the configuration tip, but it works by setting the > --class-path and --module-path options in the <arguments> block of the > exec-maven-plugin. My issue was also execution with surefire, javadoc, > etc. All plugins need the same configuration. > It is the same there, nothing relates to depency type (which is my point). > > > 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). > > > Global configuration is also desirable. Per-plugin tuning may also be > desirable, but there is good chances that they would be modifications of > the global configuration instead of something independent (providing > that the global configuration has the <type> proposal). > I see a lot of overlap but no 1-1 cases except on simple projects. Compiler != Surefire != Javadoc for ex, this is why type looks very limiting until combinable or each plugin has filter capability which also mean type is useless. > > > Agree, default should stay classpath and module path shouldn't be > > enabled until requested, creates too much weird behaviors IMHO. > > > Weird behaviour happens when the library is not on the path it was > designed for. Weird behaviour if we put a designed-for-class-path > dependency on the module-path, and potentially broken behaviour if we > put a designed-for-module-path dependency on the class-path. The reason > why we do not observe the latter often is because library producers are > aware that the Java world is still a lot class-path centric, and > provides workaround in their library for making execution on class-path > possible. > Exactly! > Martin > >
