Le mar. 31 oct. 2023 à 00:22, Tamás Cservenák <ta...@cservenak.net> a écrit :
> Oh, and just as "dependency reduced pom", the flatten does not work within > the reactor _either_. > This part should be solved with consumer pom but within the reactor you should get the same behavior in terms of dep with flattening anything. Stays the multiartifacts issue where we still have a single pom but that is a maven module design issue. But yes, relocation and uber jar have the issue they are not well resolved today and this is a reactor thing since a single artifact thing, agree. > In fact, the existence of a flatten plugin per se is an IMHO sign that > "something is wrong" here. > We solved the pipeline for it so guess we passed it. Flatten is more about cutting transitive visitor which is insanely slow with resolver today. > Thanks > T > > On Tue, Oct 31, 2023 at 12:08 AM Romain Manni-Bucau <rmannibu...@gmail.com > > > wrote: > > > Hmm, new types are not a real option for that, it is fully the lifecycle > > (plugin chain thesz days since lifecycles are never rich enough and it > > depends too much on projects. > > > > Your fatjar example is not a type but the flatten plugin presence and it > is > > really not a type cause it implies a specific pom resolution which is out > > of the artifact (type) handling scope. > > IMHO we must not break that rule and not abuse of the resolver, it is > > already overcomplex for its role....and once again does not help with > jpms > > or plugin config set outside very few plugin scope. > > > > If you use types for this fatjar dep handling you also require downstream > > projects to consume all their upstream chain plugins and handlers which > is > > not doable in real life so sticking to the fair minimum is wishable > (agree > > we wrongly added types as workarounds). > > > > > > Le lun. 30 oct. 2023 à 22:00, Tamás Cservenák <ta...@cservenak.net> a > > écrit : > > > > > ... makes resolver STOP _whatever_ the referenced POM list as > > dependencies > > > (basically does not matter, the node once collected will NOT dive into > > > getting possible children). > > > > > > T > > > > > > On Mon, Oct 30, 2023 at 9:58 PM Tamás Cservenák <ta...@cservenak.net> > > > wrote: > > > > > > > The fat* mechanism is already present even in maven 3.9, but not so > > > > visible: > > > > > > > > > > > > > > https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L51 > > > > > > > > Is "fat" when this method returns true. > > > > > > > > Moreover, the new type would give you (as a consumer) more control, > it > > > > allows you to NOT depend on upstream publisher (is he rewriting POM? > > Does > > > > he do a good job rewriting it? etc). If you declare your dependency > as > > > > "fatjar" and not just "jar", or "fatmodule" not just "module", it > makes > > > > resolver STOP. > > > > > > > > Thanks > > > > T > > > > > > > > On Mon, Oct 30, 2023 at 9:53 PM Tamás Cservenák <ta...@cservenak.net > > > > > > wrote: > > > > > > > >> Howdy, > > > >> > > > >> The fat* is needed to STOP resolver resolving further external > > > >> dependencies (or in-reactor ones), it gives you more control to > > > _express_ > > > >> this case to Maven. > > > >> > > > >> Typical case: > > > >> - you have in reactor "uber" JAR built (with replace POM set) > > > >> - hence, you deploy the rewritten POM, so for consumers you are OK > > > >> - BUT _within reactor_ Maven will NOT (and cannot) be aware of > > > >> _rewritten_ module, so you need to "exclude all" in subsequent > modules > > > >> depending on uber module: > > > >> > > > >> https://github.com/maveniverse/mima/blob/main/cli/pom.xml#L83-L94 > > > >> So, this one would need to be type="fatjar" and result would be same > > but > > > >> more expressive: > > > >> > > > >> Basically these just extend the "vocabulary" to express what it is. > > > >> > > > >> T > > > >> > > > >> On Mon, Oct 30, 2023 at 9:35 PM Henning Schmiedehausen < > > > >> henn...@schmiedehausen.org> wrote: > > > >> > > > >>> I don't understand fatjar and fatmodule. Why would we need that? > How > > > >>> would > > > >>> maven treat this different from a regular jar / module ? > > > >>> > > > >>> -h > > > >>> > > > >>> > > > >>> > > > >>> On Sun, Oct 29, 2023 at 8:10 AM Tamás Cservenák < > ta...@cservenak.net > > > > > > >>> wrote: > > > >>> > > > >>> > Howdy, > > > >>> > > > > >>> > The current draft of types we want to introduce (and packaging): > > > >>> > https://gist.github.com/cstamas/4e9bcbef25ce912a90ad1e127b0c5db8 > > > >>> > > > > >>> > === > > > >>> > > > > >>> > Romain, I don't understand your "This is wrong, downstream is > > either > > > >>> module > > > >>> > or jar", as it was actually you and your example that mentioned > > "once > > > >>> put > > > >>> > it here, once put it there". Nothing is lost IMHO, just like in > > case > > > of > > > >>> > "takari-jar" nothing is lost. > > > >>> > > > > >>> > Or if we misunderstood each other: by "downstream" I mean "down > the > > > >>> road, > > > >>> > when a project being built, is about to be consumed as > dependency". > > > >>> > > > > >>> > And the point is, that exactly due > > ArtifactHandler/ArtifactType/Type > > > >>> (in > > > >>> > mvn4), Maven "sees" it as "jar" or "module" or whatever, but for > > > >>> resolver, > > > >>> > those two are _same thing_. It is _same file_. And this is the > > crux, > > > >>> as for > > > >>> > the resolver, it is really about getting that one file, while the > > > type > > > >>> (for > > > >>> > Maven) tells HOW to make use of it. So for resolving, there is no > > any > > > >>> kind > > > >>> > of "lost" information, again, the very same way it works for > > > >>> "takari-jar". > > > >>> > > > > >>> > T > > > >>> > > > > >>> > On Sun, Oct 29, 2023 at 3:52 PM Romain Manni-Bucau < > > > >>> rmannibu...@gmail.com> > > > >>> > wrote: > > > >>> > > > > >>> > > Le dim. 29 oct. 2023 à 15:29, Tamás Cservenák < > > ta...@cservenak.net > > > > > > > >>> a > > > >>> > > écrit : > > > >>> > > > > > >>> > > > Howdy, > > > >>> > > > > > > >>> > > > So to return to the "root" idea (of Maven), Maven is > > > "declarative", > > > >>> > where > > > >>> > > > users should declare what they want, it should most certainly > > not > > > >>> > "guess" > > > >>> > > > what user intent is. As long as we have "magical implicit > > > >>> guesswork" > > > >>> > > (like > > > >>> > > > that in javadoc) present in process, it is bad, as that means > > we > > > >>> do not > > > >>> > > > allow our users to express their goal. > > > >>> > > > > > > >>> > > > > > >>> > > Yes and i liked that but we broke it with forcing plugin > version > > > >>> locking > > > >>> > > (for good) so we can need to revise our root too to match > current > > > >>> world > > > >>> > > which is no more unique, makes years we ignore that fact but it > > > >>> already > > > >>> > > blows up. > > > >>> > > > > > >>> > > So my 2cts are we cant by design here, we tried hard and > failed, > > > not > > > >>> > > technically but by design. > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > Originally Mojos were envisioned to be simple, focused, doing > > one > > > >>> thing > > > >>> > > and > > > >>> > > > doing it well (a la UNIX tools). Some plugins went in the > total > > > >>> > opposite > > > >>> > > > direction, as they became Godzilla plugins (with > unmaintainable > > > >>> complex > > > >>> > > and > > > >>> > > > large amounts of "logic" -- guess logic and bloated codebase) > > > >>> targeting > > > >>> > > to > > > >>> > > > solve "everything". This also resulted in our users assuming > > > "every > > > >>> > > problem > > > >>> > > > should have a corresponding Mojo" (this also steered toward > > > >>> bloated, > > > >>> > over > > > >>> > > > complex Mojos), where many many other aspects and > capabilities > > of > > > >>> Maven > > > >>> > > > were totally neglected, like lifecycle, custom packaging and > so > > > on. > > > >>> > > > > > > >>> > > > In short, Romain, yes, today, you CAN build all sort of > things > > in > > > >>> > "smart > > > >>> > > > way", just like cooking a soup: get a good base (packaging), > > add > > > a > > > >>> > little > > > >>> > > > bit of this (mojo A) and a little bit of that (mojo B) and > > voila, > > > >>> you > > > >>> > > will > > > >>> > > > end up with a "soup". And it works, yes, but this "smart" way > > has > > > >>> many > > > >>> > > > pitfalls along the way, with most problematic of not being > > > >>> explicit. > > > >>> > But > > > >>> > > by > > > >>> > > > doing that, your build becomes Ant-ish (imperative-ish), and > > you > > > >>> are > > > >>> > > > sliding off the declarative path. > > > >>> > > > > > > >>> > > > > > >>> > > For cases needing it and all the mentionned ones are (and will) > > NOT > > > >>> (be) > > > >>> > > mainstream. > > > >>> > > So all good IMHO. > > > >>> > > > > > >>> > > > > > >>> > > > Also, you ARE aware that if you build a project w/ > > > packaging=module > > > >>> > (that > > > >>> > > > as output has an artifact with extension jar), you DON'T HAVE > > TO > > > >>> > address > > > >>> > > it > > > >>> > > > downstream (when you depend on it) as "module", right? This > is > > > the > > > >>> > actual > > > >>> > > > reason why I brought up Takari Lifecycle, as there you are > > > building > > > >>> > > > projects with packaging=takari-jar, but when you consume > those, > > > you > > > >>> > refer > > > >>> > > > to them as type=jar, and not as type=takari-jar, right? > > > >>> > > > > > > >>> > > > > > >>> > > This is wrong, downstream is either module or jar, here you > loose > > > if > > > >>> it > > > >>> > is > > > >>> > > a module transitively and module assume all transitive deps are > > > >>> which is > > > >>> > > very often wrong so it does not work downstream. > > > >>> > > > > > >>> > > > > > >>> > > > So, I have a feeling that you bring bold conclusions (like > > "Your > > > >>> > solution > > > >>> > > > is valid technically but does not solve the original issue"), > > you > > > >>> do > > > >>> > not > > > >>> > > > really understand what I am trying to say here. > > > >>> > > > > > > >>> > > > > > >>> > > Hooe you are true but trust me i went where you are and my > > > >>> conclusion is > > > >>> > it > > > >>> > > cant be done right for enough projects to be worth it. > > > >>> > > > > > >>> > > > > > >>> > > > Also, "this" certainly does NOT "work well today" (even in > this > > > >>> thread > > > >>> > > poor > > > >>> > > > tooling mentioned), but true, you can hack-around it, or > alike, > > > but > > > >>> > none > > > >>> > > of > > > >>> > > > current solutions are explicit, declarative and naturally > > > >>> expressed in > > > >>> > > > Maven (but are bolted on). > > > >>> > > > > > > >>> > > > Finally, having anything "on top" of resolver is not gonna > help > > > >>> > anything, > > > >>> > > > as Resolver is really about Artifacts only (Everything is an > > > >>> Artifact!) > > > >>> > > and > > > >>> > > > it is Maven on top of Resolver that should interpret these > > > >>> artifacts > > > >>> > > based > > > >>> > > > on user posed instructions (declarations). Resolver is really > > > just > > > >>> > about > > > >>> > > > "getting" and "putting" artifacts, not USING them. > > > >>> > > > > > > >>> > > > > > >>> > > It foes cause it is not aboug resolver but enabling user to > > express > > > >>> path > > > >>> > > with maven abstraction, not resolution itself. > > > >>> > > > > > >>> > > Java is about paths, maven coordinates, we miss a link on user > > land > > > >>> to > > > >>> > make > > > >>> > > it smooth. > > > >>> > > > > > >>> > > > > > >>> > > > Thanks > > > >>> > > > T > > > >>> > > > > > > >>> > > > > > > >>> > > > On Sun, Oct 29, 2023 at 2:56 PM Tamás Cservenák < > > > >>> ta...@cservenak.net> > > > >>> > > > wrote: > > > >>> > > > > > > >>> > > > > Romain, > > > >>> > > > > > > > >>> > > > > it's probably me, but I have no faintest idea what you are > > > >>> trying to > > > >>> > > > say... > > > >>> > > > > > > > >>> > > > > What do you mean by "standalone"? > > > >>> > > > > What is the wrong packaging? > > > >>> > > > > Why will I lose the ability to specify where it goes? Also, > > as > > > I > > > >>> said > > > >>> > > > > before, if you list project/deps gav:jar AND gav:module, > you > > > >>> would be > > > >>> > > > > putting _one same JAR_ on both paths (would you really want > > > >>> that?) > > > >>> > > > > Also, here we are speaking about _dependencies_ but you > > > suddenly > > > >>> > switch > > > >>> > > > to > > > >>> > > > > building a project? > > > >>> > > > > > > > >>> > > > > But one thing for sure: we need _less_ "guess logic" and > not > > > >>> _more of > > > >>> > > > it_. > > > >>> > > > > > > > >>> > > > > I think we are not talking about the same thing(s) here, > but > > > >>> again, > > > >>> > > it's > > > >>> > > > > just maybe me. > > > >>> > > > > > > > >>> > > > > T > > > >>> > > > > > > > >>> > > > > On Sun, Oct 29, 2023 at 1:32 PM Romain Manni-Bucau < > > > >>> > > > rmannibu...@gmail.com> > > > >>> > > > > wrote: > > > >>> > > > > > > > >>> > > > >> Le dim. 29 oct. 2023 à 12:44, Tamás Cservenák < > > > >>> ta...@cservenak.net> > > > >>> > a > > > >>> > > > >> écrit : > > > >>> > > > >> > > > >>> > > > >> > Can you provide a real example? As I don't quite > > understand, > > > >>> so > > > >>> > you > > > >>> > > > >> would > > > >>> > > > >> > have a dependency (a fat spring boot jar), that is a > > "module > > > >>> dep > > > >>> > is > > > >>> > > a > > > >>> > > > >> > module in compile/some tests but not at runtime (spring > > boot > > > >>> > > fatjar)". > > > >>> > > > >> So > > > >>> > > > >> > all this within one maven module > (compile/test/runtime?). > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > >> > > > >>> > > > >> You have an app (src/main/java), all the chain down the > line > > > >>> uses > > > >>> > > > modules > > > >>> > > > >> cause compiler is standalone, surefire (junit-launcher) is > > > >>> > standalone, > > > >>> > > > >> javadoc etc...and the packaging phase (jar/war/fatjar/...) > > is > > > >>> not > > > >>> > > > >> standalone. > > > >>> > > > >> Then using module will make your build pass but your IT > (if > > > you > > > >>> have > > > >>> > > > else > > > >>> > > > >> your runtime) will not use that kind of > > construction/runtime. > > > >>> > > > >> the issue is as soon as you mark them modules then it must > > be > > > >>> module > > > >>> > > for > > > >>> > > > >> all plugins and therefore you will get a wrong packaging > > > (think > > > >>> bnd > > > >>> > > for > > > >>> > > > >> ex) > > > >>> > > > >> or said otherwise you loose the consumption ability the > JVM > > > has > > > >>> > > > providing > > > >>> > > > >> both classpath and module path for the same jar (jlink > > > requires > > > >>> deps > > > >>> > > to > > > >>> > > > be > > > >>> > > > >> modules but these modules can be used in the classpath > most > > of > > > >>> the > > > >>> > > time, > > > >>> > > > >> in > > > >>> > > > >> particular in tests where it helps in several scenarii > like > > > >>> > mocking). > > > >>> > > > >> > > > >>> > > > >> These are all valid features we don't want to break in > > maven. > > > >>> > > > >> > > > >>> > > > >> The consuming side is problematic since you restart from > > > >>> scratch, > > > >>> > all > > > >>> > > > the > > > >>> > > > >> jpms meta are to throw away cause we don't want to break > the > > > >>> model > > > >>> > on > > > >>> > > > one > > > >>> > > > >> side and on another side it depends the consumer the way > you > > > >>> consume > > > >>> > > it > > > >>> > > > >> and > > > >>> > > > >> dispatch the dependency on the classpath or module path. > > > >>> > > > >> > > > >>> > > > >> Your solution is valid technically but does not solve the > > > >>> original > > > >>> > > > issue, > > > >>> > > > >> it just moves it elsewhere IMHO. > > > >>> > > > >> > > > >>> > > > >> This already works well today at the cost of being > explicit > > in > > > >>> the > > > >>> > > > plugins > > > >>> > > > >> configs and with your proposal it will still work at the > > same > > > >>> cost > > > >>> > > > (maybe > > > >>> > > > >> reversed). > > > >>> > > > >> > > > >>> > > > >> So ultimately I don't think it is a dep meta we need but > > more > > > a > > > >>> > > wrapper > > > >>> > > > on > > > >>> > > > >> top of the resolver (the guess logic we have in plexus for > > ex) > > > >>> which > > > >>> > > > >> should > > > >>> > > > >> be easier to configure, maybe globally for the project and > > > >>> > ultimately > > > >>> > > > per > > > >>> > > > >> plugin (think "configuration" in gradle world of maven > > > >>> depencies set > > > >>> > > in > > > >>> > > > >> our > > > >>> > > > >> world)....or we just don't do anything and ease the > > dependency > > > >>> > > > referencing > > > >>> > > > >> (gav->path) to ease this explicit configuration - a bit > like > > > >>> > including > > > >>> > > > >> dependencies:properties in core by default. > > > >>> > > > >> > > > >>> > > > >> > > > >>> > > > >> > > > >>> > > > >> > > > >>> > > > >> > > > > >>> > > > >> > T > > > >>> > > > >> > > > > >>> > > > >> > On Sun, Oct 29, 2023 at 12:37 PM Romain Manni-Bucau < > > > >>> > > > >> rmannibu...@gmail.com > > > >>> > > > >> > > > > > >>> > > > >> > wrote: > > > >>> > > > >> > > > > >>> > > > >> > > Le dim. 29 oct. 2023 à 12:12, Tamás Cservenák < > > > >>> > > ta...@cservenak.net> > > > >>> > > > a > > > >>> > > > >> > > écrit : > > > >>> > > > >> > > > > > >>> > > > >> > > > Given that jar (spring boot fatjar) is once this > once > > > >>> that, > > > >>> > you > > > >>> > > > >> refer > > > >>> > > > >> > to > > > >>> > > > >> > > it > > > >>> > > > >> > > > in deps as needed: > > > >>> > > > >> > > > in one module is fat:jar in other is fat:module, as > > > >>> needed. > > > >>> > > > >> > > > > > > >>> > > > >> > > > You are the one explicitly telling what you want. > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > In my example (and spring boot is not the only one, > wars > > > are > > > >>> > > another > > > >>> > > > >> > common > > > >>> > > > >> > > one, or any java command more generally) the two > modules > > > >>> are a > > > >>> > > > single > > > >>> > > > >> > > one....and no doing two module would be worse than > what > > we > > > >>> have > > > >>> > > > today. > > > >>> > > > >> > > > > > >>> > > > >> > > > > > >>> > > > >> > > > Thanks > > > >>> > > > >> > > > T > > > >>> > > > >> > > > > > > >>> > > > >> > > > On Sun, Oct 29, 2023 at 8:42 AM Romain Manni-Bucau < > > > >>> > > > >> > > rmannibu...@gmail.com> > > > >>> > > > >> > > > wrote: > > > >>> > > > >> > > > > > > >>> > > > >> > > > > Interesting but common case: a module dep is a > > module > > > in > > > >>> > > > >> compile/some > > > >>> > > > >> > > > tests > > > >>> > > > >> > > > > but not at runtime (spring boot fatjar). > > > >>> > > > >> > > > > Back to explicit config in plugins and drop new > > module > > > >>> type? > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > Le dim. 29 oct. 2023 à 07:46, Christoph Läubrich < > > > >>> > > > >> > m...@laeubi-soft.de> > > > >>> > > > >> > > a > > > >>> > > > >> > > > > écrit : > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > where properties are totally extensible, > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > And if now I could supply additional properties > > from > > > >>> the > > > >>> > > > >> xml-model > > > >>> > > > >> > > ... > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > Am 29.10.23 um 00:40 schrieb Tamás Cservenák: > > > >>> > > > >> > > > > > > And finally this is hardly gonna happen in > > Maven 3 > > > >>> > > lifespan, > > > >>> > > > >> as > > > >>> > > > >> > > sadly > > > >>> > > > >> > > > > > > ArtifactHandler of it is quite limited: has > only > > > one > > > >>> > flag: > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > > > > https://github.com/apache/maven/blob/maven-3.9.x/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L55 > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > Sadly, Maven4 Type continued on this path, but > > > >>> luckily > > > >>> > we > > > >>> > > > are > > > >>> > > > >> in > > > >>> > > > >> > > > alpha, > > > >>> > > > >> > > > > > and > > > >>> > > > >> > > > > > > will propose a PR to type that currently looks > > > like > > > >>> > this: > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > > > > https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Type.java#L80 > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > And would rework it to be more (if not same > as) > > > the > > > >>> > > resolver > > > >>> > > > >> > > > > > ArtifactType: > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > > > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java#L63 > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > where properties are totally extensible, for > > > example > > > >>> > "add > > > >>> > > to > > > >>> > > > >> > > > classpath" > > > >>> > > > >> > > > > > is > > > >>> > > > >> > > > > > > really just one flag (added by ArifactType): > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > > > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactProperties.java#L58 > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > So, ArtifactProperties could be extended with > > > >>> > > > >> > > > "constitutesModulePath", > > > >>> > > > >> > > > > > > "agent" and so on... To make this really > > > extensible. > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > In maven3 the ArtifactHandler this makes it > > > >>> impossible. > > > >>> > > > There > > > >>> > > > >> is > > > >>> > > > >> > > > still > > > >>> > > > >> > > > > > hope > > > >>> > > > >> > > > > > > in Maven 4 > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > Thanks > > > >>> > > > >> > > > > > > T > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > On Sun, Oct 29, 2023 at 12:32 AM Tamás > > Cservenák < > > > >>> > > > >> > > > ta...@cservenak.net> > > > >>> > > > >> > > > > > > wrote: > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > >> This would also mean, that if you have a > > > dependency > > > >>> > that > > > >>> > > is > > > >>> > > > >> > > already > > > >>> > > > >> > > > > JPMS > > > >>> > > > >> > > > > > >> modularized (is java9+ and has module-info), > > > then: > > > >>> > > > >> > > > > > >> > > > >>> > > > >> > > > > > >> a) if you declare it as type="jar" it means > you > > > >>> want to > > > >>> > > put > > > >>> > > > >> it > > > >>> > > > >> > on > > > >>> > > > >> > > > > > >> classpath (use it as "plain old jar") > > > >>> > > > >> > > > > > >> b) if you declare it as type="module" it > means > > > you > > > >>> want > > > >>> > > it > > > >>> > > > on > > > >>> > > > >> > > > > modulepath > > > >>> > > > >> > > > > > >> etc > > > >>> > > > >> > > > > > >> > > > >>> > > > >> > > > > > >> On Sun, Oct 29, 2023 at 12:30 AM Tamás > > Cservenák > > > < > > > >>> > > > >> > > > ta...@cservenak.net > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > >> wrote: > > > >>> > > > >> > > > > > >> > > > >>> > > > >> > > > > > >>> Of course, the logic HOW and WHAT to make > with > > > >>> these > > > >>> > > would > > > >>> > > > >> be > > > >>> > > > >> > > > needed > > > >>> > > > >> > > > > to > > > >>> > > > >> > > > > > >>> be added to javadoc, compiler and all the > > > plugins > > > >>> that > > > >>> > > > need > > > >>> > > > >> to > > > >>> > > > >> > > > > > distinguish. > > > >>> > > > >> > > > > > >>> But this would stop any need for any > > heuristic, > > > >>> > > guesswork, > > > >>> > > > >> > > > > smart-ness, > > > >>> > > > >> > > > > > >>> etc... > > > >>> > > > >> > > > > > >>> > > > >>> > > > >> > > > > > >>> OTOH, if we introduce new packaging > lifecycle > > > >>> "module" > > > >>> > > > (so a > > > >>> > > > >> > > > project > > > >>> > > > >> > > > > > that > > > >>> > > > >> > > > > > >>> builds module would do > > > project/packaging=module), > > > >>> it > > > >>> > > could > > > >>> > > > >> > nicely > > > >>> > > > >> > > > > > enforce > > > >>> > > > >> > > > > > >>> things like: > > > >>> > > > >> > > > > > >>> - prevent non allowed packages > > > >>> > > > >> > > > > > >>> - enforce presence of module-info.class > (maybe > > > >>> some > > > >>> > > light > > > >>> > > > >> > > > > verification) > > > >>> > > > >> > > > > > >>> - ensure project is Java9+ etc > > > >>> > > > >> > > > > > >>> > > > >>> > > > >> > > > > > >>> Most of this was somewhat done in Takari > > > Lifecycle > > > >>> > (also > > > >>> > > > >> with > > > >>> > > > >> > > > custom > > > >>> > > > >> > > > > > >>> packaging like "takari-jar" was). > > > >>> > > > >> > > > > > >>> > > > >>> > > > >> > > > > > >>> > > > >>> > > > >> > > > > > >>> T > > > >>> > > > >> > > > > > >>> > > > >>> > > > >> > > > > > >>> On Sun, Oct 29, 2023 at 12:26 AM Tamás > > > Cservenák < > > > >>> > > > >> > > > > ta...@cservenak.net> > > > >>> > > > >> > > > > > >>> wrote: > > > >>> > > > >> > > > > > >>> > > > >>> > > > >> > > > > > >>>> So, basically this is what am proposing: > > > >>> > > > >> > > > > > >>>> > > > >>> > > > >> > > > > > >>> > https://gist.github.com/cstamas/76f262538b5a11f6ee23d6d8c86f10ec > > > >>> > > > >> > > > > > >>>> > > > >>> > > > >> > > > > > >>>> Basically, Maven core (and hence plugins) > > could > > > >>> > > > distinguish > > > >>> > > > >> > > among > > > >>> > > > >> > > > > > >>>> different "types" of dependencies (while > > would > > > >>> all > > > >>> > > still > > > >>> > > > be > > > >>> > > > >> > > plain > > > >>> > > > >> > > > > > JARs). > > > >>> > > > >> > > > > > >>>> So "jar" would be put on classpath, > "module" > > on > > > >>> > module > > > >>> > > > >> path, > > > >>> > > > >> > > > "agent" > > > >>> > > > >> > > > > > >>>> would got special treatment and so on. > > > >>> > > > >> > > > > > >>>> > > > >>> > > > >> > > > > > >>>> Point is to _differentiate_. > > > >>> > > > >> > > > > > >>>> > > > >>> > > > >> > > > > > >>>> T > > > >>> > > > >> > > > > > >>>> > > > >>> > > > >> > > > > > >>>> On Sun, Oct 29, 2023 at 12:21 AM Tamás > > > Cservenák > > > >>> < > > > >>> > > > >> > > > > ta...@cservenak.net > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > >>>> wrote: > > > >>> > > > >> > > > > > >>>> > > > >>> > > > >> > > > > > >>>>> Unsure from where you get that, but is > wrong > > > >>> > > conclusion. > > > >>> > > > >> > > > > > >>>>> > > > >>> > > > >> > > > > > >>>>> You can have dep1:jar, dep2:module, > > dep3:agent > > > >>> and > > > >>> > > all 3 > > > >>> > > > >> MAY > > > >>> > > > >> > > > > > >>>>> (ArtifactHandler dependent, assuming > "jar", > > > >>> "module" > > > >>> > > and > > > >>> > > > >> > > "agent" > > > >>> > > > >> > > > > > artifact > > > >>> > > > >> > > > > > >>>>> handlers all return extension=jar) refer > to > > > the > > > >>> same > > > >>> > > JAR > > > >>> > > > >> file > > > >>> > > > >> > > in > > > >>> > > > >> > > > > > your local > > > >>> > > > >> > > > > > >>>>> repository. > > > >>> > > > >> > > > > > >>>>> > > > >>> > > > >> > > > > > >>>>> Type merely adds "semantics" WHAT is it > > about, > > > >>> HOW > > > >>> > to > > > >>> > > > make > > > >>> > > > >> > use > > > >>> > > > >> > > of > > > >>> > > > >> > > > > it. > > > >>> > > > >> > > > > > >>>>> Please see > > > >>> > > > >> > > > > > >>>>> > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > > > > https://maven.apache.org/repositories/artifacts.html#but-where-do-i-set-artifact-extension > > > >>> > > > >> > > > > > >>>>> > > > >>> > > > >> > > > > > >>>>> Thanks > > > >>> > > > >> > > > > > >>>>> T > > > >>> > > > >> > > > > > >>>>> > > > >>> > > > >> > > > > > >>>>> On Sun, Oct 29, 2023 at 12:17 AM Martin > > > >>> > Desruisseaux < > > > >>> > > > >> > > > > > >>>>> martin.desruisse...@geomatys.com> wrote: > > > >>> > > > >> > > > > > >>>>> > > > >>> > > > >> > > > > > >>>>>> Le 2023-10-28 à 22 h 54, Tamás Cservenák > a > > > >>> écrit : > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > >>>>>>> I still see these just as new dependency > > > >>> types: > > > >>> > > > >> "module", > > > >>> > > > >> > > > > "agent", > > > >>> > > > >> > > > > > >>>>>>> "doclet", and so on. > > > >>> > > > >> > > > > > >>>>>>> > > > >>> > > > >> > > > > > >>>>>> Does "dependency type" means the <type> > > > element > > > >>> > > inside > > > >>> > > > >> > > > > <dependency>? > > > >>> > > > >> > > > > > >>>>>> If > > > >>> > > > >> > > > > > >>>>>> yes, then specifying a different type > > causes > > > >>> Maven > > > >>> > to > > > >>> > > > >> > > download a > > > >>> > > > >> > > > > > >>>>>> different JAR, without changing the kind > of > > > >>> path > > > >>> > > (class > > > >>> > > > >> path > > > >>> > > > >> > > > > versus > > > >>> > > > >> > > > > > >>>>>> module path) where the JAR is put. The > > > proposed > > > >>> > > <usage> > > > >>> > > > >> > > element > > > >>> > > > >> > > > > (or > > > >>> > > > >> > > > > > >>>>>> whatever equivalent alternatives) has the > > > >>> opposite > > > >>> > > > >> semantic: > > > >>> > > > >> > > it > > > >>> > > > >> > > > > does > > > >>> > > > >> > > > > > >>>>>> not > > > >>> > > > >> > > > > > >>>>>> change the JAR to download, but put it > on a > > > >>> > different > > > >>> > > > >> kind > > > >>> > > > >> > of > > > >>> > > > >> > > > > path. > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > >>>>>> Martin > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > >>> > > > > > --------------------------------------------------------------------- > > > >>> > > > >> > > > > > >>>>>> To unsubscribe, e-mail: > > > >>> > > > dev-unsubscr...@maven.apache.org > > > >>> > > > >> > > > > > >>>>>> For additional commands, e-mail: > > > >>> > > > >> dev-h...@maven.apache.org > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > >>>>>> > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > >>> > > > > > --------------------------------------------------------------------- > > > >>> > > > >> > > > > > To unsubscribe, e-mail: > > > >>> dev-unsubscr...@maven.apache.org > > > >>> > > > >> > > > > > For additional commands, e-mail: > > > >>> > dev-h...@maven.apache.org > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > > > > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > >> > > > > > >
