Ps (seems i lost a paragraph): how does it work in consumer pom, breaks most consumers which will assume right a single jar cant be found twice in deps no?
Le sam. 4 nov. 2023 à 14:39, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit : > I still see it as abusing of extension to create sets. > Means you can only do it while it is jars - how would it work with .jmod > for ext? > > Now the critical part: how do plugin know about it? > > Ie is it better to define a ton of potentially conflicting default names + > add name config in all plugins or just let plugin configure an artifact > filter and not change anything to our model keeping type for extensions > most of the time. > > I clearly vote for this last option and -0.1for type usage cause it is > less intrusive and more generic but if you assume all exts are always jar > and all plugins get types config, agree it can work even if dirty in terms > of design IMHO. > > Le sam. 4 nov. 2023 à 13:50, Tamás Cservenák <ta...@cservenak.net> a > écrit : > >> Like this >> https://gist.github.com/cstamas/dd3795fd47f15a28d48a8c03fa9dd939 >> >> This is completely legal from mvn pov (no warning, unlike same artifact in >> two scopes) >> >> T >> >> >> On Sat, Nov 4, 2023, 13:48 Romain Manni-Bucau <rmannibu...@gmail.com> >> wrote: >> >> > How does an artifact has 2 types (it is the main issue with this >> design)? >> > >> > Le sam. 4 nov. 2023 à 11:05, Tamás Cservenák <ta...@cservenak.net> a >> > écrit : >> > >> > > So, just for fun, I used MIMA /w local mods (MIMA is vanilla mvn39 >> > models + >> > > resolver1) to resolve one of my demo modules: >> > > (neglect the root type of "dinosaur"...Also, this is really >> simplified, >> > > _resolving_ this graph would FAIL, as MIMA has no idea what "module" >> type >> > > is, as can be seen in GAVs, where extension="module"=type) >> > > https://gist.github.com/cstamas/79f9a01d661209fe302ba92b0de9ab69 >> > > >> > > It shows how even pure resolver 1.x behaves, just check the tree for >> > > "annotation-processor" and "module" types, everything is there. >> > > Basically, even though resolver1 API is able to express these things, >> the >> > > problem is that the Maven3 API is not (ArtifactHandler). >> > > >> > > T >> > > >> > > On Sat, Nov 4, 2023 at 10:43 AM Tamás Cservenák <ta...@cservenak.net> >> > > wrote: >> > > >> > > > Well, I have to disagree... >> > > > >> > > > Maven Core has no idea what "add to classpath" means, and the flag >> is >> > not >> > > > even used in core. Same would stand for MP etc. >> > > > Maven Core (simplified: the POM) tells WHAT IT IS only. >> > > > >> > > > Maven Plugin is the one who uses the core provided information to >> > process >> > > > things. So Plugin should know HOW TO USE IT. >> > > > >> > > > This is an important distinction in Maven, as otherwise plugin logic >> > > would >> > > > creep into core (like it did with site in Maven2) or other way >> > around... >> > > > >> > > > Basically, IMO types are good as it is, as you describe what it is >> (or >> > > > what you think it is), and plugin by using APIs (and yes, maybe some >> > > > "hints" from config) should be able to deduce how to make use of >> those >> > > > things. >> > > > >> > > > >> > > > On Sat, Nov 4, 2023 at 10:35 AM Romain Manni-Bucau < >> > > rmannibu...@gmail.com> >> > > > wrote: >> > > > >> > > >> 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 >> > > >> > >> > > > >> > > >> > >> > > > >> > > >> > >> > > >> > > >> > >> > >> > > >> > >> >> > > >> > > >> > > >> > >> > > >> >> > > > >> > > >> > >> >
