Just 5 cents: Plugins (as "consumer of dependency") would NOT handle with type _directlty_, but the _flags_.
So, if you look at this table (a bit outdated): https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 m-compiler-p: handles artifacts flagged with CP, MP, AP m-javadoc-p: handles artifacts flagged with DOC and so on (just roughly to explain the idea). And nothing stops you to declare as many types as many needed (to describe what you want), the plugins will go for flags only. So in short: plugins will not go for type, the go for flags defined by types (and many type can use same flag) T On Fri, Nov 3, 2023 at 9:31 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > > > >
