Yes, this is the part I find broken in maven design (even mvn3) 1nd hope we stop abusing. Also note it keeps the flag per maven module whereas we have a need per plugin. So first step is to fix plugin config to get them filters of artifacts per their "paths" and sounds like it will be sufficient, no? Type would just make some non sufficient (maybe convenient, im not convinced from my XP but will not fight on this) default and transitive issues but sounds like solething to do some years after the plugin config fix.
Do we want to normalize the way to filter maven module artifacts in plugin configs? Le sam. 4 nov. 2023 à 10:25, Tamás Cservenák <ta...@cservenak.net> a écrit : > 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 > >> > > > > >> > > > > >> > > > >> > > >> > > >
