Romain, the "fat" flag was always present, since Maven 3.0 (with introduction of resolver). Really, nothing new here. Even you already use it (without knowing).
Resolver is (and was) abused currently (see my other mail), this is more to unleash its potential instead. 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 > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > >> > > > > > >>> > > > >> > > > > >>> > > > >> > > > >>> > > > >> > > >>> > > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >> > > >
