Howdy, Unsure about your remark "you are still not solving the transitivity":
As consume-module in Maven debug outputs this (but, debug shows only scope not type, as before whole universe was "jar"): [DEBUG] org.cstamas.maven.jpms.modular:consume-module:jar:1.0.0-SNAPSHOT [DEBUG] info.picocli:picocli:jar:4.7.5:compile [DEBUG] info.picocli:picocli-codegen:jar:4.7.5:compile [DEBUG] org.cstamas.maven.jpms.modular:project-impl:jar:1.0.0-SNAPSHOT:compile [DEBUG] org.cstamas.maven.jpms.modular:project-api:jar:1.0.0-SNAPSHOT:compile [DEBUG] org.junit.jupiter:junit-jupiter-api:jar:5.10.0:test [DEBUG] org.opentest4j:opentest4j:jar:1.3.0:test [DEBUG] org.junit.platform:junit-platform-commons:jar:1.10.0:test (version managed from 1.10.0) [DEBUG] org.apiguardian:apiguardian-api:jar:1.1.2:test And yes, project-impl and project-api ARE "module"s On Thu, Nov 2, 2023 at 8:25 AM Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > Hi Tamas, > > You table shows exactly my point: you need to be able to compose > dependencies sets (potentially named from user space) and you can *not* > define types - or any similar solution - and let plugins get their config > from there. > > If you don't you are not better than today and assume that in a maven > module you always use a jar at the same location. > > A trivial example is that if you build a jar with javadoc and a generator > tool. The generator tool (which forks) which bounds on generate-resources > likely wants lib L as a module because it has a SPI in module-info and not > META-INF (thanks java) but the war needs to take into account the > type=module (because it must ignore modules by design since it only handles > classpath as of today) but if you do you broke your build exactly as today > with the guess logic. > > Your proposal is similar to what was done for OSGi bundles but had several > side effects I prefer we don't enter in and ultimately if you want to go > that path it can belong to a github extension easily. > > Last and likely very important: you are still not solving the transitivity > so we are back to the original point, either you code without any > dependency in your reactor or you are still at the first mail of that > thread. > > I'm not sure why you absolutely want to solve it at type level but it > really can't by design due to the transitivity and control we must give per > plugin not artiact IMHO. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le jeu. 2 nov. 2023 à 00:32, Tamás Cservenák <ta...@cservenak.net> a > écrit : > > > consumer POM _especially_ remains outside of project limits (again, is > > "just outside of" but not "inside" of a reactor), so unsure what should > > that solve... > > > > the "fat" thing gives you exactly this ability, so unsure what the > problem > > here is? > > > > T > > > > On Tue, Oct 31, 2023 at 8:05 AM Romain Manni-Bucau < > rmannibu...@gmail.com> > > wrote: > > > > > 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 > > > > > > >>> > > > >> > > > > > > > > > > > >>> > > > >> > > > > > > > > > > > >>> > > > >> > > > > > > > > > > >>> > > > >> > > > > > > > > > >>> > > > >> > > > > > > > > >>> > > > >> > > > > > > > >>> > > > >> > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > >>> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
