Here is where I am currently: https://cwiki.apache.org/confluence/display/MAVEN/Experiment+-+Explicit+JPMS+support
T On Tue, Oct 31, 2023 at 12:21 AM Tamás Cservenák <ta...@cservenak.net> wrote: > Oh, and just as "dependency reduced pom", the flatten does not work within > the reactor _either_. > > In fact, the existence of a flatten plugin per se is an IMHO sign that > "something is wrong" here. > > 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 >> > >>> > > > >> > > > > > >> > >>> > > > >> > > > > > >> > >>> > > > >> > > > > >> > >>> > > > >> > > > >> > >>> > > > >> > > >> > >>> > > > >> > >> > >>> > > > >> >> > >>> > > > > >> > >>> > > > >> > >>> > > >> > >>> > >> > >>> >> > >> >> > >> >
