Re: [DISCUSS] Maven Dependency Plugin
Howdy, 0.1.3 out, got unpack ability (actually UnpackSink). Here is 0.1.3 in action, doing "side-by-side" and "overlay" way of unpack: https://gist.github.com/cstamas/36c49da724100a19feab1397e7381d0f Oh, and Martin, the sink also unpacks only "unique" artifacts, so it will not over-and-over-and-over unpack the same thing... T On Tue, Mar 26, 2024 at 9:07 PM Tamás Cservenák wrote: > Oh, and as a side effect, the plugin is way more snappier as well, look at > execution time diffs (I know, this is not "benchmark", but is telling): > https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51 > > toolbox needs almost only 60% of runtime that m-dep-p have. > > T > > On Tue, Mar 26, 2024 at 8:56 PM Tamás Cservenák > wrote: > >> Rudimentary support for those is already present (equals, startWith, >> endsWith) :) >> >> So one can write ArtifactMatcher "spec expression" (that will be parsed >> into ArtifactMatcher that is actually Predicate) as: >> "artifact(gavoid)" >> where "gavoid" can be "string" or "g:a" or "g:a:v" etc >> Each field currently support: >> * - any >> foo - equals foo >> foo* - "starts with foo" >> *foo - "ends with foo" >> >> Here is UT >> >> https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java >> >> So for your case, to filter dependencies by classifier it would be >> >> "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance >> that filters for "classifier ends with x86". >> "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance >> that filters for "classifier starts with native". >> etc >> >> key to interpret is here: >> >> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250 >> and that prototype is later used here >> >> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84 >> >> T >> >> >> >> >> >> On Tue, Mar 26, 2024 at 8:41 PM Francois Marot >> wrote: >> >>> Thanks Tamas for all your work. I'll sure have a look (but not right now >>> as >>> I'm in a train station on a phone). Just to mention a feature I missed >>> yesterday in m-d-p: ability to filter on classifiers including >>> *wildcards*. >>> Because I have dependencies with this kind of classifiers: natives-win, >>> natives-linux, natives-x86, natives-amd64 and so on... >>> >>> Wildcard are sometimes a feature I miss in many plugins. >>> Thanks again for the work, wildcards or not ! >>> >>> Francois >>> >>> Le mar. 26 mars 2024, 17:58, Tamás Cservenák a >>> écrit : >>> >>> > Just for those brave... if you toy with it. >>> > >>> > The "copy" and "copy-transitive" CLI commands and Mojos have >>> "targetSpec" >>> > parameters, that are parsed into ArtifactSink here: >>> > >>> > >>> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 >>> > >>> > So, the copy (and copy-transitive) resolve (transitively) and push the >>> > results into an ArtifactSink. >>> > >>> > Sink spec can be: >>> > "foo" -> implied "flat:foo" >>> > "flat:" -> a "flat directory" to copy artifacts to, like >>> "flat:lib" >>> > (is resolved from basedir) >>> > "repository:" -> creates a repo that can be used as "file://" >>> uri or >>> > published via HTTP (is resolved from basedir) >>> > "install:" -> will install them into local repository (session >>> > default in no path specified), ie. good to prep a local repo -- TBD >>> >>> > param >>> > "deploy:id::url" -> will deploy them to Remote Repo >>> > "purge:" -> will purge them from local repository (session >>> default in >>> > no path specified) -- TBD param >>> > >>> > So, following command: >>> > >>> > copy -DdepSpec="any()" -DtargetSpec="purge:" >>> > >>> > actually does the purge from the local repository. Same stands for >>> gav-copy >>> > (and gav-copy-transitively), but they do not use MavenProject to >>> > "contextualize" but need to be told explicitly what to resolve... >>> > >>> > >>> > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák >>> > wrote: >>> > >>> > > Howdy, >>> > > >>> > > Yes, m-dep-p is under maintained, it actually would need a rewrite >>> as it >>> > > still uses MAT (and many other Maven2 archaic stuff) internally. >>> > > Hence, it will fail if used with 3.9+ features like "split >>> repository" >>> > and >>> > > is suboptimal in many areas. >>> > > >>> > > Toolbox 0.1.0 released, btw: >>> > > >>> > > jbang toolbox@maveniverse >>> > > >>> > > or >>> > > >>> > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl >>> > > >>> > > to enter REPL (same as in MIMA CLI was). >>> > > >>> > > T >>> > > >>> > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala >> > >>> > > wrote: >>> > > >>> > >> Hello Tamás, >>> > >> >>> > >> For context, what are the tensions that you're trying to
Re: [DISCUSS] Maven Dependency Plugin
Oh, and as a side effect, the plugin is way more snappier as well, look at execution time diffs (I know, this is not "benchmark", but is telling): https://gist.github.com/cstamas/6026436527cbd669ce1a5f183f03fe51 toolbox needs almost only 60% of runtime that m-dep-p have. T On Tue, Mar 26, 2024 at 8:56 PM Tamás Cservenák wrote: > Rudimentary support for those is already present (equals, startWith, > endsWith) :) > > So one can write ArtifactMatcher "spec expression" (that will be parsed > into ArtifactMatcher that is actually Predicate) as: > "artifact(gavoid)" > where "gavoid" can be "string" or "g:a" or "g:a:v" etc > Each field currently support: > * - any > foo - equals foo > foo* - "starts with foo" > *foo - "ends with foo" > > Here is UT > > https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java > > So for your case, to filter dependencies by classifier it would be > > "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance > that filters for "classifier ends with x86". > "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance > that filters for "classifier starts with native". > etc > > key to interpret is here: > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250 > and that prototype is later used here > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84 > > T > > > > > > On Tue, Mar 26, 2024 at 8:41 PM Francois Marot > wrote: > >> Thanks Tamas for all your work. I'll sure have a look (but not right now >> as >> I'm in a train station on a phone). Just to mention a feature I missed >> yesterday in m-d-p: ability to filter on classifiers including >> *wildcards*. >> Because I have dependencies with this kind of classifiers: natives-win, >> natives-linux, natives-x86, natives-amd64 and so on... >> >> Wildcard are sometimes a feature I miss in many plugins. >> Thanks again for the work, wildcards or not ! >> >> Francois >> >> Le mar. 26 mars 2024, 17:58, Tamás Cservenák a >> écrit : >> >> > Just for those brave... if you toy with it. >> > >> > The "copy" and "copy-transitive" CLI commands and Mojos have >> "targetSpec" >> > parameters, that are parsed into ArtifactSink here: >> > >> > >> https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 >> > >> > So, the copy (and copy-transitive) resolve (transitively) and push the >> > results into an ArtifactSink. >> > >> > Sink spec can be: >> > "foo" -> implied "flat:foo" >> > "flat:" -> a "flat directory" to copy artifacts to, like >> "flat:lib" >> > (is resolved from basedir) >> > "repository:" -> creates a repo that can be used as "file://" uri >> or >> > published via HTTP (is resolved from basedir) >> > "install:" -> will install them into local repository (session >> > default in no path specified), ie. good to prep a local repo -- TBD >> >> > param >> > "deploy:id::url" -> will deploy them to Remote Repo >> > "purge:" -> will purge them from local repository (session >> default in >> > no path specified) -- TBD param >> > >> > So, following command: >> > >> > copy -DdepSpec="any()" -DtargetSpec="purge:" >> > >> > actually does the purge from the local repository. Same stands for >> gav-copy >> > (and gav-copy-transitively), but they do not use MavenProject to >> > "contextualize" but need to be told explicitly what to resolve... >> > >> > >> > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák >> > wrote: >> > >> > > Howdy, >> > > >> > > Yes, m-dep-p is under maintained, it actually would need a rewrite as >> it >> > > still uses MAT (and many other Maven2 archaic stuff) internally. >> > > Hence, it will fail if used with 3.9+ features like "split repository" >> > and >> > > is suboptimal in many areas. >> > > >> > > Toolbox 0.1.0 released, btw: >> > > >> > > jbang toolbox@maveniverse >> > > >> > > or >> > > >> > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl >> > > >> > > to enter REPL (same as in MIMA CLI was). >> > > >> > > T >> > > >> > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala >> > > wrote: >> > > >> > >> Hello Tamás, >> > >> >> > >> For context, what are the tensions that you're trying to solve here? >> > >> >> > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen >> > sink? >> > >> >> > >> Do some goals feel like a bad fit? >> > >> >> > >> Are you thinking of breaking it up or replacing it? >> > >> >> > >> Greg >> > >> >> > >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > > >> > >> wrote: >> > >> >> > >> > Howdy, >> > >> > >> > >> > just to not let this discussion die off. Let me show a take on a >> "how >> > >> > modern Maven plugin should look like" (that targets m-dependency-p >> > >> goals, >>
Re: [DISCUSS] Maven Dependency Plugin
Rudimentary support for those is already present (equals, startWith, endsWith) :) So one can write ArtifactMatcher "spec expression" (that will be parsed into ArtifactMatcher that is actually Predicate) as: "artifact(gavoid)" where "gavoid" can be "string" or "g:a" or "g:a:v" etc Each field currently support: * - any foo - equals foo foo* - "starts with foo" *foo - "ends with foo" Here is UT https://github.com/maveniverse/toolbox/blob/main/shared/src/test/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcherTest.java So for your case, to filter dependencies by classifier it would be "artifact(*:*:*x86:*)" => it would parse into ArtifactMatcher instance that filters for "classifier ends with x86". "artifact(*:*:native*:*)" => it would parse into ArtifactMatcher instance that filters for "classifier starts with native". etc key to interpret is here: https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L225-L250 and that prototype is later used here https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ArtifactMatcher.java#L77-L84 T On Tue, Mar 26, 2024 at 8:41 PM Francois Marot wrote: > Thanks Tamas for all your work. I'll sure have a look (but not right now as > I'm in a train station on a phone). Just to mention a feature I missed > yesterday in m-d-p: ability to filter on classifiers including *wildcards*. > Because I have dependencies with this kind of classifiers: natives-win, > natives-linux, natives-x86, natives-amd64 and so on... > > Wildcard are sometimes a feature I miss in many plugins. > Thanks again for the work, wildcards or not ! > > Francois > > Le mar. 26 mars 2024, 17:58, Tamás Cservenák a > écrit : > > > Just for those brave... if you toy with it. > > > > The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec" > > parameters, that are parsed into ArtifactSink here: > > > > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 > > > > So, the copy (and copy-transitive) resolve (transitively) and push the > > results into an ArtifactSink. > > > > Sink spec can be: > > "foo" -> implied "flat:foo" > > "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib" > > (is resolved from basedir) > > "repository:" -> creates a repo that can be used as "file://" uri > or > > published via HTTP (is resolved from basedir) > > "install:" -> will install them into local repository (session > > default in no path specified), ie. good to prep a local repo -- TBD > > > param > > "deploy:id::url" -> will deploy them to Remote Repo > > "purge:" -> will purge them from local repository (session default > in > > no path specified) -- TBD param > > > > So, following command: > > > > copy -DdepSpec="any()" -DtargetSpec="purge:" > > > > actually does the purge from the local repository. Same stands for > gav-copy > > (and gav-copy-transitively), but they do not use MavenProject to > > "contextualize" but need to be told explicitly what to resolve... > > > > > > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > Yes, m-dep-p is under maintained, it actually would need a rewrite as > it > > > still uses MAT (and many other Maven2 archaic stuff) internally. > > > Hence, it will fail if used with 3.9+ features like "split repository" > > and > > > is suboptimal in many areas. > > > > > > Toolbox 0.1.0 released, btw: > > > > > > jbang toolbox@maveniverse > > > > > > or > > > > > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl > > > > > > to enter REPL (same as in MIMA CLI was). > > > > > > T > > > > > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala > > > wrote: > > > > > >> Hello Tamás, > > >> > > >> For context, what are the tensions that you're trying to solve here? > > >> > > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen > > sink? > > >> > > >> Do some goals feel like a bad fit? > > >> > > >> Are you thinking of breaking it up or replacing it? > > >> > > >> Greg > > >> > > >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > > >> wrote: > > >> > > >> > Howdy, > > >> > > > >> > just to not let this discussion die off. Let me show a take on a > "how > > >> > modern Maven plugin should look like" (that targets m-dependency-p > > >> goals, > > >> > sans analyze and some others) could look like: > > >> > https://github.com/maveniverse/toolbox > > >> > > > >> > The "unpack" related goals are missing, not yet done, but there are > > >> already > > >> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally > > same > > >> as > > >> > CLI commands, and they do NOT require Project, are meant to be "ad > > hoc" > > >> > invoked. > > >> > The non-"gav-"-prefixed mojos use MavenProject instead to > > >> "contextualize" > > >> > themselves (so they
Re: [DISCUSS] Maven Dependency Plugin
Thanks Tamas for all your work. I'll sure have a look (but not right now as I'm in a train station on a phone). Just to mention a feature I missed yesterday in m-d-p: ability to filter on classifiers including *wildcards*. Because I have dependencies with this kind of classifiers: natives-win, natives-linux, natives-x86, natives-amd64 and so on... Wildcard are sometimes a feature I miss in many plugins. Thanks again for the work, wildcards or not ! Francois Le mar. 26 mars 2024, 17:58, Tamás Cservenák a écrit : > Just for those brave... if you toy with it. > > The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec" > parameters, that are parsed into ArtifactSink here: > > https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 > > So, the copy (and copy-transitive) resolve (transitively) and push the > results into an ArtifactSink. > > Sink spec can be: > "foo" -> implied "flat:foo" > "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib" > (is resolved from basedir) > "repository:" -> creates a repo that can be used as "file://" uri or > published via HTTP (is resolved from basedir) > "install:" -> will install them into local repository (session > default in no path specified), ie. good to prep a local repo -- TBD > param > "deploy:id::url" -> will deploy them to Remote Repo > "purge:" -> will purge them from local repository (session default in > no path specified) -- TBD param > > So, following command: > > copy -DdepSpec="any()" -DtargetSpec="purge:" > > actually does the purge from the local repository. Same stands for gav-copy > (and gav-copy-transitively), but they do not use MavenProject to > "contextualize" but need to be told explicitly what to resolve... > > > On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák > wrote: > > > Howdy, > > > > Yes, m-dep-p is under maintained, it actually would need a rewrite as it > > still uses MAT (and many other Maven2 archaic stuff) internally. > > Hence, it will fail if used with 3.9+ features like "split repository" > and > > is suboptimal in many areas. > > > > Toolbox 0.1.0 released, btw: > > > > jbang toolbox@maveniverse > > > > or > > > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl > > > > to enter REPL (same as in MIMA CLI was). > > > > T > > > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala > > wrote: > > > >> Hello Tamás, > >> > >> For context, what are the tensions that you're trying to solve here? > >> > >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen > sink? > >> > >> Do some goals feel like a bad fit? > >> > >> Are you thinking of breaking it up or replacing it? > >> > >> Greg > >> > >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > >> wrote: > >> > >> > Howdy, > >> > > >> > just to not let this discussion die off. Let me show a take on a "how > >> > modern Maven plugin should look like" (that targets m-dependency-p > >> goals, > >> > sans analyze and some others) could look like: > >> > https://github.com/maveniverse/toolbox > >> > > >> > The "unpack" related goals are missing, not yet done, but there are > >> already > >> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally > same > >> as > >> > CLI commands, and they do NOT require Project, are meant to be "ad > hoc" > >> > invoked. > >> > The non-"gav-"-prefixed mojos use MavenProject instead to > >> "contextualize" > >> > themselves (so they work with the Project, and the "plugin-" prefixed > >> ones > >> > with Project defined plugins). > >> > > >> > Note1: not yet released (is not on Central), if you want to test drive > >> it, > >> > build it locally). > >> > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the > CLI > >> > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > >> > Note3: some of the missing goals mentioned on this thread are > >> implemented > >> > > >> > Thanks > >> > T > >> > > >> > > >
Re: [DISCUSS] Maven Dependency Plugin
Just for those brave... if you toy with it. The "copy" and "copy-transitive" CLI commands and Mojos have "targetSpec" parameters, that are parsed into ArtifactSink here: https://github.com/maveniverse/toolbox/blob/main/shared/src/main/java/eu/maveniverse/maven/toolbox/shared/internal/ToolboxCommandoImpl.java#L251-L288 So, the copy (and copy-transitive) resolve (transitively) and push the results into an ArtifactSink. Sink spec can be: "foo" -> implied "flat:foo" "flat:" -> a "flat directory" to copy artifacts to, like "flat:lib" (is resolved from basedir) "repository:" -> creates a repo that can be used as "file://" uri or published via HTTP (is resolved from basedir) "install:" -> will install them into local repository (session default in no path specified), ie. good to prep a local repo -- TBD param "deploy:id::url" -> will deploy them to Remote Repo "purge:" -> will purge them from local repository (session default in no path specified) -- TBD param So, following command: copy -DdepSpec="any()" -DtargetSpec="purge:" actually does the purge from the local repository. Same stands for gav-copy (and gav-copy-transitively), but they do not use MavenProject to "contextualize" but need to be told explicitly what to resolve... On Tue, Mar 26, 2024 at 5:34 PM Tamás Cservenák wrote: > Howdy, > > Yes, m-dep-p is under maintained, it actually would need a rewrite as it > still uses MAT (and many other Maven2 archaic stuff) internally. > Hence, it will fail if used with 3.9+ features like "split repository" and > is suboptimal in many areas. > > Toolbox 0.1.0 released, btw: > > jbang toolbox@maveniverse > > or > > mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl > > to enter REPL (same as in MIMA CLI was). > > T > > On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala > wrote: > >> Hello Tamás, >> >> For context, what are the tensions that you're trying to solve here? >> >> Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? >> >> Do some goals feel like a bad fit? >> >> Are you thinking of breaking it up or replacing it? >> >> Greg >> >> On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák >> wrote: >> >> > Howdy, >> > >> > just to not let this discussion die off. Let me show a take on a "how >> > modern Maven plugin should look like" (that targets m-dependency-p >> goals, >> > sans analyze and some others) could look like: >> > https://github.com/maveniverse/toolbox >> > >> > The "unpack" related goals are missing, not yet done, but there are >> already >> > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same >> as >> > CLI commands, and they do NOT require Project, are meant to be "ad hoc" >> > invoked. >> > The non-"gav-"-prefixed mojos use MavenProject instead to >> "contextualize" >> > themselves (so they work with the Project, and the "plugin-" prefixed >> ones >> > with Project defined plugins). >> > >> > Note1: not yet released (is not on Central), if you want to test drive >> it, >> > build it locally). >> > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI >> > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) >> > Note3: some of the missing goals mentioned on this thread are >> implemented >> > >> > Thanks >> > T >> > >> >
Re: [DISCUSS] Maven Dependency Plugin
Howdy, Yes, m-dep-p is under maintained, it actually would need a rewrite as it still uses MAT (and many other Maven2 archaic stuff) internally. Hence, it will fail if used with 3.9+ features like "split repository" and is suboptimal in many areas. Toolbox 0.1.0 released, btw: jbang toolbox@maveniverse or mvn mvn eu.maveniverse.maven.plugins:toolbox:0.1.0:gav-repl to enter REPL (same as in MIMA CLI was). T On Tue, Mar 26, 2024 at 4:51 PM Greg Chabala wrote: > Hello Tamás, > > For context, what are the tensions that you're trying to solve here? > > Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? > > Do some goals feel like a bad fit? > > Are you thinking of breaking it up or replacing it? > > Greg > > On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák > wrote: > > > Howdy, > > > > just to not let this discussion die off. Let me show a take on a "how > > modern Maven plugin should look like" (that targets m-dependency-p goals, > > sans analyze and some others) could look like: > > https://github.com/maveniverse/toolbox > > > > The "unpack" related goals are missing, not yet done, but there are > already > > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same > as > > CLI commands, and they do NOT require Project, are meant to be "ad hoc" > > invoked. > > The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" > > themselves (so they work with the Project, and the "plugin-" prefixed > ones > > with Project defined plugins). > > > > Note1: not yet released (is not on Central), if you want to test drive > it, > > build it locally). > > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI > > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > > Note3: some of the missing goals mentioned on this thread are implemented > > > > Thanks > > T > > >
Re: [DISCUSS] Maven Dependency Plugin
Hello Tamás, For context, what are the tensions that you're trying to solve here? Is m-dependency-p too big/getting unmaintainable/becoming a kitchen sink? Do some goals feel like a bad fit? Are you thinking of breaking it up or replacing it? Greg On Tue, Mar 26, 2024 at 8:52 AM Tamás Cservenák wrote: > Howdy, > > just to not let this discussion die off. Let me show a take on a "how > modern Maven plugin should look like" (that targets m-dependency-p goals, > sans analyze and some others) could look like: > https://github.com/maveniverse/toolbox > > The "unpack" related goals are missing, not yet done, but there are already > 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same as > CLI commands, and they do NOT require Project, are meant to be "ad hoc" > invoked. > The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" > themselves (so they work with the Project, and the "plugin-" prefixed ones > with Project defined plugins). > > Note1: not yet released (is not on Central), if you want to test drive it, > build it locally). > Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI > uber is toolbox-1.0.0-SNAPSHOT-cli.jar) > Note3: some of the missing goals mentioned on this thread are implemented > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
Howdy, just to not let this discussion die off. Let me show a take on a "how modern Maven plugin should look like" (that targets m-dependency-p goals, sans analyze and some others) could look like: https://github.com/maveniverse/toolbox The "unpack" related goals are missing, not yet done, but there are already 33 Mojos in there. Most Mojos that are "gav-" prefixed are totally same as CLI commands, and they do NOT require Project, are meant to be "ad hoc" invoked. The non-"gav-"-prefixed mojos use MavenProject instead to "contextualize" themselves (so they work with the Project, and the "plugin-" prefixed ones with Project defined plugins). Note1: not yet released (is not on Central), if you want to test drive it, build it locally). Note2: the "toolbox" is Maven Plugin and a CLI at the same time (the CLI uber is toolbox-1.0.0-SNAPSHOT-cli.jar) Note3: some of the missing goals mentioned on this thread are implemented Thanks T On Sat, Mar 23, 2024 at 9:43 AM Oliver B. Fischer wrote: > Yes, all of them. > > purge-local-repository I use very often in Jenkins pipelines to clean up > afterwards. > > Over the years I build a lot of pipelines, added checks to projects and so > on. The dependency plugin was very often my rescue. I can't remember each > single usage and project and its context, but there is a reason why these > goals/functions have been added. > > Oliver > > > > > Am 21.03.24 um 19:43 schrieb Tamás Cservenák: > > Howdy, > > > > Oliver: all, really? > > I wonder what you used for goals like "purge-local-repository", > > "resolve-plugins" etc :) > > > > I mean, I know what those goals do, I am just unsure WHY you needed > those. > > > > T > > > > On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer< > o.b.fisc...@swe-blog.net> > > wrote: > > > >> Hi, > >> > >> over the time I used all of them in different projects and I think all > >> of them are needed. > >> > >> Viele Grüße > >> > >> Oliver > >> > >> > >> Am 21.03.24 um 17:04 schrieb Tamás Cservenák: > >>> Howdy, > >>> > >>> I'd would be interested in how users and devs are using > >>> maven-dependency-plugin: > >>> https://maven.apache.org/plugins/maven-dependency-plugin/ > >>> > >>> I collected some basic questions I'd like to have answered (but feel > free > >>> to add more info!): > >>> - which goals are "must have" for you > >>> - which goals are "I never touched" for you (or, "I really don't need" > or > >>> "never used" or "shrug") > >>> - what is missing? > >>> > >>> Thanks > >>> T > >>> > >> -- > >> N Oliver B. Fischer > >> A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > >> P +49 30 44793251 > >> M +49 178 7903538 > >> eo.b.fisc...@swe-blog.net > >> > >> > >> - > >> To unsubscribe, e-mail:users-unsubscr...@maven.apache.org > >> For additional commands, e-mail:users-h...@maven.apache.org > >> > >> > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > eo.b.fisc...@swe-blog.net >
Re: [DISCUSS] Maven Dependency Plugin
Yes, all of them. purge-local-repository I use very often in Jenkins pipelines to clean up afterwards. Over the years I build a lot of pipelines, added checks to projects and so on. The dependency plugin was very often my rescue. I can't remember each single usage and project and its context, but there is a reason why these goals/functions have been added. Oliver Am 21.03.24 um 19:43 schrieb Tamás Cservenák: Howdy, Oliver: all, really? I wonder what you used for goals like "purge-local-repository", "resolve-plugins" etc :) I mean, I know what those goals do, I am just unsure WHY you needed those. T On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer wrote: Hi, over the time I used all of them in different projects and I think all of them are needed. Viele Grüße Oliver Am 21.03.24 um 17:04 schrieb Tamás Cservenák: Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 eo.b.fisc...@swe-blog.net - To unsubscribe, e-mail:users-unsubscr...@maven.apache.org For additional commands, e-mail:users-h...@maven.apache.org -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 eo.b.fisc...@swe-blog.net
Re: [DISCUSS] Maven Dependency Plugin
I most frequently use tree and analyze, but have used others like the copy* and unpack* goals, too. I do miss an equivalent to tree for plugin dependencies. -- Alexander Kriegisch https://scrum-master.de Tamás Cservenák schrieb am 21.03.2024 17:04 (GMT +01:00): > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Many downstream package maintainers use :go-offline to build packages offline in a container w/o outbound network access. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
czw., 21 mar 2024 o 20:54 Tamás Cservenák napisał(a): > Howdy, > > What is the use case of "go offline"? > For me - I use go-offline to prefetch local repo. I have a simple project which have a common dependencies like spring-boot and some home made other commons dependencies in company, On this project I execute go-offline from time to time on git-lab Next other projects use prefeched repo as maven.repo.local.tail, each project uses its own cached local repo, repositories not used by some time are removed. All cached repositories are mounted by nfs on git-lub runners - so I minimize using the same repo by many build to avoid locks problems I know that go offline has many bugs ... but it is accepted in my scenario > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > +1 to this list from Slawomir: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > s.jaranow...@gmail.com> > > wrote: > > > > > Hi > > > I use: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > napisał(a): > > > > > > > Howdy, > > > > > > > > I'd would be interested in how users and devs are using > > > > maven-dependency-plugin: > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > I collected some basic questions I'd like to have answered (but feel > > free > > > > to add more info!): > > > > - which goals are "must have" for you > > > > - which goals are "I never touched" for you (or, "I really don't > need" > > or > > > > "never used" or "shrug") > > > > - what is missing? > > > > > > > > Thanks > > > > T > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > > -- Sławomir Jaranowski
Re: [DISCUSS] Maven Dependency Plugin
Hey !
First of all, for everyone asking more info to understand where the pom
values come from and how they are computed, I think a very useful command
is:
**
mvn org.apache.maven.plugins:maven-help-plugin:3.4.0:effective-pom
-Dverbose=true
**
It will display your effective pom but also will tell you in comments for
each value where (which pom) it comes from.
Regarding the dependency plugin, what I use very frequently:
* copy-dependencies (including all the options)
* tree
What may be usefull to me
* analyze-*
* build-classpath
* dependency:unpack-dependencies (see below)
For the record, I forked/rewrote a plugin kinda similar to the
unpack-dependencies specifically aimed at unzipping zip or tar.gz
containing dlls being identified by the classifier "natives-win" or
"natives-linux": https://github.com/fmarot/nativedependencies-maven
The main selling point to this plugin is its speed in a multi-module
project (I have 150 modules needing native dependencies being unzipped in
their PATH for the tests) because it keeps record of the unpacked
dependencies and will skip unpacking the same dependency again and again
when you want all the dlls being unpacked at
${session.executionRootDirectory}\target\natives for example.
Regards,
François
Le jeu. 21 mars 2024 à 17:06, Tamás Cservenák a
écrit :
> Howdy,
>
> I'd would be interested in how users and devs are using
> maven-dependency-plugin:
> https://maven.apache.org/plugins/maven-dependency-plugin/
>
> I collected some basic questions I'd like to have answered (but feel free
> to add more info!):
> - which goals are "must have" for you
> - which goals are "I never touched" for you (or, "I really don't need" or
> "never used" or "shrug")
> - what is missing?
>
> Thanks
> T
>
Re: [DISCUSS] Maven Dependency Plugin
Greg, For example, we recently converted the TrinoDB ( https://github.com/trinodb/trino) build, removed their use of "go offline" So am just interested in any other patterns out there. T On Thu, Mar 21, 2024 at 9:40 PM Greg Chabala wrote: > I do have an example at hand, though I am not sure I would advocate for it: > https://blog.frankel.ch/faster-maven-builds/2/ > > There are undoubtedly better ways to achieve the author's goals, but I'm > not sure that's the fault of dependency:go-offline. > > On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák > wrote: > > > Greg, > > > > would like to see such a project, do you have any examples at hand? > > Am sure there are much simpler/better/more correct ways to do the same > > thing. > > > > T > > > > On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala > > wrote: > > > > > My understanding is dependency:go-offline is an effective way to > > > pre-download plugins and dependencies, for instance if one is making > some > > > layer in a docker build container for later reuse. > > > > > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > > > wrote: > > > > > > > Howdy, > > > > > > > > What is the use case of "go offline"? > > > > That is yet another goal coming from "Maven2 era" and messes up your > > > local > > > > repository (wrt back tracing dependencies, > > > > https://issues.apache.org/jira/browse/MNG-7619) > > > > I mean, if you do a build (w/o tests, or skipping most time stealing > > > > steps), like "dry build", why is that not an option? > > > > > > > > T > > > > > > > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz > > wrote: > > > > > > > > > +1 to this list from Slawomir: > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > - dependency:copy > > > > > - dependency:copy-dependencies > > > > > - dependency:go-offline > > > > > - dependency:list > > > > > - dependency:tree > > > > > - dependency:unpack > > > > > - dependency:unpack-dependencies > > > > > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > > > s.jaranow...@gmail.com> > > > > > wrote: > > > > > > > > > > > Hi > > > > > > I use: > > > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > > - dependency:copy > > > > > > - dependency:copy-dependencies > > > > > > - dependency:go-offline > > > > > > - dependency:list > > > > > > - dependency:tree > > > > > > - dependency:unpack > > > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > > > napisał(a): > > > > > > > > > > > > > Howdy, > > > > > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > > > maven-dependency-plugin: > > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > > > > > I collected some basic questions I'd like to have answered (but > > > feel > > > > > free > > > > > > > to add more info!): > > > > > > > - which goals are "must have" for you > > > > > > > - which goals are "I never touched" for you (or, "I really > don't > > > > need" > > > > > or > > > > > > > "never used" or "shrug") > > > > > > > - what is missing? > > > > > > > > > > > > > > Thanks > > > > > > > T > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
I do have an example at hand, though I am not sure I would advocate for it: https://blog.frankel.ch/faster-maven-builds/2/ There are undoubtedly better ways to achieve the author's goals, but I'm not sure that's the fault of dependency:go-offline. On Thu, Mar 21, 2024 at 3:19 PM Tamás Cservenák wrote: > Greg, > > would like to see such a project, do you have any examples at hand? > Am sure there are much simpler/better/more correct ways to do the same > thing. > > T > > On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala > wrote: > > > My understanding is dependency:go-offline is an effective way to > > pre-download plugins and dependencies, for instance if one is making some > > layer in a docker build container for later reuse. > > > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > What is the use case of "go offline"? > > > That is yet another goal coming from "Maven2 era" and messes up your > > local > > > repository (wrt back tracing dependencies, > > > https://issues.apache.org/jira/browse/MNG-7619) > > > I mean, if you do a build (w/o tests, or skipping most time stealing > > > steps), like "dry build", why is that not an option? > > > > > > T > > > > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz > wrote: > > > > > > > +1 to this list from Slawomir: > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > - dependency:copy > > > > - dependency:copy-dependencies > > > > - dependency:go-offline > > > > - dependency:list > > > > - dependency:tree > > > > - dependency:unpack > > > > - dependency:unpack-dependencies > > > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > > s.jaranow...@gmail.com> > > > > wrote: > > > > > > > > > Hi > > > > > I use: > > > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > > - dependency:copy > > > > > - dependency:copy-dependencies > > > > > - dependency:go-offline > > > > > - dependency:list > > > > > - dependency:tree > > > > > - dependency:unpack > > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > > napisał(a): > > > > > > > > > > > Howdy, > > > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > > maven-dependency-plugin: > > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > > > I collected some basic questions I'd like to have answered (but > > feel > > > > free > > > > > > to add more info!): > > > > > > - which goals are "must have" for you > > > > > > - which goals are "I never touched" for you (or, "I really don't > > > need" > > > > or > > > > > > "never used" or "shrug") > > > > > > - what is missing? > > > > > > > > > > > > Thanks > > > > > > T > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sławomir Jaranowski > > > > > > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
Greg, would like to see such a project, do you have any examples at hand? Am sure there are much simpler/better/more correct ways to do the same thing. T On Thu, Mar 21, 2024 at 9:15 PM Greg Chabala wrote: > My understanding is dependency:go-offline is an effective way to > pre-download plugins and dependencies, for instance if one is making some > layer in a docker build container for later reuse. > > On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák > wrote: > > > Howdy, > > > > What is the use case of "go offline"? > > That is yet another goal coming from "Maven2 era" and messes up your > local > > repository (wrt back tracing dependencies, > > https://issues.apache.org/jira/browse/MNG-7619) > > I mean, if you do a build (w/o tests, or skipping most time stealing > > steps), like "dry build", why is that not an option? > > > > T > > > > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > > > +1 to this list from Slawomir: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > > s.jaranow...@gmail.com> > > > wrote: > > > > > > > Hi > > > > I use: > > > > > > > > - dependency:analyze / dependency:analyze-only > > > > - dependency:copy > > > > - dependency:copy-dependencies > > > > - dependency:go-offline > > > > - dependency:list > > > > - dependency:tree > > > > - dependency:unpack > > > > - dependency:unpack-dependencies > > > > > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > > napisał(a): > > > > > > > > > Howdy, > > > > > > > > > > I'd would be interested in how users and devs are using > > > > > maven-dependency-plugin: > > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > > > I collected some basic questions I'd like to have answered (but > feel > > > free > > > > > to add more info!): > > > > > - which goals are "must have" for you > > > > > - which goals are "I never touched" for you (or, "I really don't > > need" > > > or > > > > > "never used" or "shrug") > > > > > - what is missing? > > > > > > > > > > Thanks > > > > > T > > > > > > > > > > > > > > > > > -- > > > > Sławomir Jaranowski > > > > > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
My understanding is dependency:go-offline is an effective way to pre-download plugins and dependencies, for instance if one is making some layer in a docker build container for later reuse. On Thu, Mar 21, 2024 at 2:54 PM Tamás Cservenák wrote: > Howdy, > > What is the use case of "go offline"? > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > > > +1 to this list from Slawomir: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > > s.jaranow...@gmail.com> > > wrote: > > > > > Hi > > > I use: > > > > > > - dependency:analyze / dependency:analyze-only > > > - dependency:copy > > > - dependency:copy-dependencies > > > - dependency:go-offline > > > - dependency:list > > > - dependency:tree > > > - dependency:unpack > > > - dependency:unpack-dependencies > > > > > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > > napisał(a): > > > > > > > Howdy, > > > > > > > > I'd would be interested in how users and devs are using > > > > maven-dependency-plugin: > > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > > > I collected some basic questions I'd like to have answered (but feel > > free > > > > to add more info!): > > > > - which goals are "must have" for you > > > > - which goals are "I never touched" for you (or, "I really don't > need" > > or > > > > "never used" or "shrug") > > > > - what is missing? > > > > > > > > Thanks > > > > T > > > > > > > > > > > > > -- > > > Sławomir Jaranowski > > > > > >
Re: [DISCUSS] Maven Dependency Plugin
So, in Maven2, the local repo was really "just a bunch of files" (totally wild west). With Maven3, and Resolver (yes, this is true from 3.0) the "enhanced" local repository is used, that tries to "track" origin (of cached, not installed) artifacts. In Maven 3.9 the next step is made, which is a "split local repository", where files (as opposed to "enhanced") are physically kept in split locations. All goals and plugins that _assume_ that local repository is "just a bunch of files" are wrong, and should be avoided. (this was the reason for all the plugin warnings in Maven 3.9.x line as well, to make them stand out, and have plugin authors make the step of correcting them, or users abandoning them) A related typical example was https://issues.apache.org/jira/browse/MASSEMBLY-957 where it was "assumed" that "local" and "remote" repository notion is interchangeable. Is not. These (mis)conceptions must go away. T On Thu, Mar 21, 2024 at 8:54 PM Tamás Cservenák wrote: > Howdy, > > What is the use case of "go offline"? > That is yet another goal coming from "Maven2 era" and messes up your local > repository (wrt back tracing dependencies, > https://issues.apache.org/jira/browse/MNG-7619) > I mean, if you do a build (w/o tests, or skipping most time stealing > steps), like "dry build", why is that not an option? > > T > > > On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > >> +1 to this list from Slawomir: >> >> - dependency:analyze / dependency:analyze-only >> - dependency:copy >> - dependency:copy-dependencies >> - dependency:go-offline >> - dependency:list >> - dependency:tree >> - dependency:unpack >> - dependency:unpack-dependencies >> >> On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < >> s.jaranow...@gmail.com> >> wrote: >> >> > Hi >> > I use: >> > >> > - dependency:analyze / dependency:analyze-only >> > - dependency:copy >> > - dependency:copy-dependencies >> > - dependency:go-offline >> > - dependency:list >> > - dependency:tree >> > - dependency:unpack >> > - dependency:unpack-dependencies >> > >> > >> > >> > czw., 21 mar 2024 o 17:06 Tamás Cservenák >> > napisał(a): >> > >> > > Howdy, >> > > >> > > I'd would be interested in how users and devs are using >> > > maven-dependency-plugin: >> > > https://maven.apache.org/plugins/maven-dependency-plugin/ >> > > >> > > I collected some basic questions I'd like to have answered (but feel >> free >> > > to add more info!): >> > > - which goals are "must have" for you >> > > - which goals are "I never touched" for you (or, "I really don't >> need" or >> > > "never used" or "shrug") >> > > - what is missing? >> > > >> > > Thanks >> > > T >> > > >> > >> > >> > -- >> > Sławomir Jaranowski >> > >> >
Re: [DISCUSS] Maven Dependency Plugin
Howdy, What is the use case of "go offline"? That is yet another goal coming from "Maven2 era" and messes up your local repository (wrt back tracing dependencies, https://issues.apache.org/jira/browse/MNG-7619) I mean, if you do a build (w/o tests, or skipping most time stealing steps), like "dry build", why is that not an option? T On Thu, Mar 21, 2024 at 8:45 PM Scott Kurz wrote: > +1 to this list from Slawomir: > > - dependency:analyze / dependency:analyze-only > - dependency:copy > - dependency:copy-dependencies > - dependency:go-offline > - dependency:list > - dependency:tree > - dependency:unpack > - dependency:unpack-dependencies > > On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski < > s.jaranow...@gmail.com> > wrote: > > > Hi > > I use: > > > > - dependency:analyze / dependency:analyze-only > > - dependency:copy > > - dependency:copy-dependencies > > - dependency:go-offline > > - dependency:list > > - dependency:tree > > - dependency:unpack > > - dependency:unpack-dependencies > > > > > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > > napisał(a): > > > > > Howdy, > > > > > > I'd would be interested in how users and devs are using > > > maven-dependency-plugin: > > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > > > I collected some basic questions I'd like to have answered (but feel > free > > > to add more info!): > > > - which goals are "must have" for you > > > - which goals are "I never touched" for you (or, "I really don't need" > or > > > "never used" or "shrug") > > > - what is missing? > > > > > > Thanks > > > T > > > > > > > > > -- > > Sławomir Jaranowski > > >
Re: [DISCUSS] Maven Dependency Plugin
+1 to this list from Slawomir: - dependency:analyze / dependency:analyze-only - dependency:copy - dependency:copy-dependencies - dependency:go-offline - dependency:list - dependency:tree - dependency:unpack - dependency:unpack-dependencies On Thu, Mar 21, 2024 at 2:56 PM Slawomir Jaranowski wrote: > Hi > I use: > > - dependency:analyze / dependency:analyze-only > - dependency:copy > - dependency:copy-dependencies > - dependency:go-offline > - dependency:list > - dependency:tree > - dependency:unpack > - dependency:unpack-dependencies > > > > czw., 21 mar 2024 o 17:06 Tamás Cservenák > napisał(a): > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > > > > -- > Sławomir Jaranowski >
Re: [DISCUSS] Maven Dependency Plugin
Like a couple of other folks 90% of my usage is dependency:analyze and dependency:tree. Other goals I barely notice. On Thu, Mar 21, 2024 at 12:06 PM Tamás Cservenák wrote: > > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Agreed, Use of "purge-local-repository" is a very bad thing (next to "go offline" and related goals). They all come from the "maven2 era", and should never be used with Maven3... T On Thu, Mar 21, 2024 at 7:50 PM Richard Eckart de Castilho wrote: > > > On 21. Mar 2024, at 19:43, Tamás Cservenák wrote: > > > > I mean, I know what those goals do, I am just unsure WHY you needed > those. > > The current Apache UIMA release guidelines still list them as suggested > steps > to perform before a local trial build to ensure locally cached artifacts do > not interfere with the build. > > https://uima.apache.org/release.html > > That said, I personally do not use these goal when I run a release build > and the new guidelines will not list them anymore - at least for the time > being... > > But I'm sure people wise then I have had a reason the include them in the > guidelines back in the day. > > -- Richard > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [DISCUSS] Maven Dependency Plugin
Hi I use: - dependency:analyze / dependency:analyze-only - dependency:copy - dependency:copy-dependencies - dependency:go-offline - dependency:list - dependency:tree - dependency:unpack - dependency:unpack-dependencies czw., 21 mar 2024 o 17:06 Tamás Cservenák napisał(a): > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T > -- Sławomir Jaranowski
Re: [DISCUSS] Maven Dependency Plugin
> On 21. Mar 2024, at 19:43, Tamás Cservenák wrote: > > I mean, I know what those goals do, I am just unsure WHY you needed those. The current Apache UIMA release guidelines still list them as suggested steps to perform before a local trial build to ensure locally cached artifacts do not interfere with the build. https://uima.apache.org/release.html That said, I personally do not use these goal when I run a release build and the new guidelines will not list them anymore - at least for the time being... But I'm sure people wise then I have had a reason the include them in the guidelines back in the day. -- Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Howdy, Oliver: all, really? I wonder what you used for goals like "purge-local-repository", "resolve-plugins" etc :) I mean, I know what those goals do, I am just unsure WHY you needed those. T On Thu, Mar 21, 2024 at 6:41 PM Oliver B. Fischer wrote: > Hi, > > over the time I used all of them in different projects and I think all > of them are needed. > > Viele Grüße > > Oliver > > > Am 21.03.24 um 17:04 schrieb Tamás Cservenák: > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > > -- > N Oliver B. Fischer > A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany > P +49 30 44793251 > M +49 178 7903538 > E o.b.fisc...@swe-blog.net > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: [DISCUSS] Maven Dependency Plugin
Hi, over the time I used all of them in different projects and I think all of them are needed. Viele Grüße Oliver Am 21.03.24 um 17:04 schrieb Tamás Cservenák: Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Hi, I mostly use the "analyze" (mostly the "analyze-only") and "tree" goals, but I have also already used "copy/unpack-dependencies", "sources", "purge-local-repository" and "resolve". IMHO the "versions" plugin has a few functionalities that feel like could also belong to the dependencies plugin, in particular goals related to checking if dependencies are up-to-date or updating dependencies to a later version. Well, I guess these goals are about versions as much as they are about dependencies... What I miss is being able to see where a particular dependency version was originally defined - "tree" only says the resolved dependencies, but e.g. not which properties were used in resolving the version and which dependencyManagement sections in which POMs (best with line numbers) were involved. Fortunately, m2eclipse can be of some help here. Cheers, -- Richard - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
Hi For me it is: * Tree: human work on transitivity * List: pre-resolve for the runtime (dump jar list in a file) * Resolve: CI init phase Le jeu. 21 mars 2024 à 17:54, Christian Stein a écrit : > I use the "resolve" goal like this: > > mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt > org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve > > ...and parse the output for Java module names and whether they are > "automatic". > > > https://github.com/sormuras/maven-starter-projects/blob/c7839302f3552caa4de42bc97aa151ddabf7bc78/src/GenerateReadme.java#L74 > > On Thu, Mar 21, 2024 at 5:06 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > >
Re: [DISCUSS] Maven Dependency Plugin
Hey, mainly tree and analyze (note: we also use enforcer-plugin with some rules for dependencies) Greetings Matthias Am 21.03.2024 um 17:04 schrieb Tamás Cservenák: Howdy, I'd would be interested in how users and devs are using maven-dependency-plugin: https://maven.apache.org/plugins/maven-dependency-plugin/ I collected some basic questions I'd like to have answered (but feel free to add more info!): - which goals are "must have" for you - which goals are "I never touched" for you (or, "I really don't need" or "never used" or "shrug") - what is missing? Thanks T - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] Maven Dependency Plugin
I use the "resolve" goal like this: mvn --batch-mode --no-transfer-progress -DoutputFile=resolved.txt org.apache.maven.plugins:maven-dependency-plugin:3.6.1:resolve ...and parse the output for Java module names and whether they are "automatic". https://github.com/sormuras/maven-starter-projects/blob/c7839302f3552caa4de42bc97aa151ddabf7bc78/src/GenerateReadme.java#L74 On Thu, Mar 21, 2024 at 5:06 PM Tamás Cservenák wrote: > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
The tree goal is my go to for this plugin. I also like the analyze. A wish I have is to get a more clearer view of the resolved dependencies version with regard to the declared dependencyManagement and/or the shortest path to dependency. For example, when I see the dependency slf4j-api with version 1.7, it would be nice to get the resolution logic maven takes to compute this 1.7 number (direct dependency with a version specified -> dependencyManagement (and when you have multiple, their ordering) -> shortest transitive path). IDE provide these (I love Eclipse dependency view) but it would be nice to have it on the cli as well. Thanks for reaching out! On Thu, Mar 21, 2024 at 12:35 PM Gary Gregory wrote: > The one I use the most from the command line is "tree" ( > https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html) > > I wish I could say "ignore test scope" to help me understand my runtime > dependencies better. > > Gary > > > On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I'd would be interested in how users and devs are using > > maven-dependency-plugin: > > https://maven.apache.org/plugins/maven-dependency-plugin/ > > > > I collected some basic questions I'd like to have answered (but feel free > > to add more info!): > > - which goals are "must have" for you > > - which goals are "I never touched" for you (or, "I really don't need" or > > "never used" or "shrug") > > - what is missing? > > > > Thanks > > T > > >
Re: [DISCUSS] Maven Dependency Plugin
The one I use the most from the command line is "tree" ( https://maven.apache.org/plugins/maven-dependency-plugin/tree-mojo.html) I wish I could say "ignore test scope" to help me understand my runtime dependencies better. Gary On Thu, Mar 21, 2024, 12:06 PM Tamás Cservenák wrote: > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
Re: [DISCUSS] Maven Dependency Plugin
Most of the time I use copy-dependencies goal to build non fat jar deployments. Meanwhile tree goal helps figure out multimodule dependency clashes by showing resolved ransitive dependencies. As for the rest, i can see where and what could use them, but I haven't used them directly. On Thu, Mar 21, 2024, 18:06 Tamás Cservenák wrote: > Howdy, > > I'd would be interested in how users and devs are using > maven-dependency-plugin: > https://maven.apache.org/plugins/maven-dependency-plugin/ > > I collected some basic questions I'd like to have answered (but feel free > to add more info!): > - which goals are "must have" for you > - which goals are "I never touched" for you (or, "I really don't need" or > "never used" or "shrug") > - what is missing? > > Thanks > T >
