So, just to explain w/ code: In Maven3 ArtifactHandler (type=id selects a handler) looks like this: https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55
And you can spot the two boolean "lfags": addedToClasspath (CP) and includesDependencies (ID). Maven4 master corresponding Type looks like this: https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80 Same two boolean flags. In my PoC PR this is generalized: https://github.com/cstamas/maven/blob/module-experiment/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java === In mvn3 realm (mvn3 plugin) here is an example how an artifact lands on CP: the flag is checked https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/TestClassPath.java#L63 And from that point on, starts the "guesswork" (is it a module maybe?) A mvn4 plugin could make much fine-grainer checks (CP, MP etc). My idea was really just to make things _explicit_. Thanks T On Sat, Nov 4, 2023 at 9:58 AM Tamás Cservenák <ta...@cservenak.net> wrote: > 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 >> > > > >> > > > >> > > >> > >> >
