Well, even mvn3 works like it today, except it has "fixed set" of flags. All i did is opened up the number of possible flags, added MP (next to existing CP flag from mvn 3). Types were really eztensible in mvn3 as well, but less expressive with fixed set of flags.
Basically even in mvn3, an artifact lands on CP if it has CP flag set... No radical change in this area. T On Sat, Nov 4, 2023, 08:49 Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Doesnt it mean you dont need type at all. > I understand the idea to add new method in the handler but this is really a > weird design and still blocked by the predefined set so user is still > locked by design so not sure how it helps to rely on type. > > Le ven. 3 nov. 2023 à 21:44, Tamás Cservenák <ta...@cservenak.net> a > écrit : > > > 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 > > > > > > > > > > > > > >
