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 > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > > > > > >> > > > > >> > > > > > > > > > >
