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