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 <ta...@cservenak.net> 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<Artifact>) 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 <francois.ma...@gmail.com> > 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 <ta...@cservenak.net> 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:<path>" -> a "flat directory" to copy artifacts to, like >> "flat:lib" >> > (is resolved from basedir) >> > "repository:<path>" -> creates a repo that can be used as "file://" uri >> or >> > published via HTTP (is resolved from basedir) >> > "install:<path>" -> will install them into local repository (session >> > default in no path specified), ie. good to prep a local repo -- TBD >> <path> >> > param >> > "deploy:id::url" -> will deploy them to Remote Repo >> > "purge:<path>" -> will purge them from local repository (session >> default in >> > no path specified) -- TBD <path> 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 <ta...@cservenak.net> >> > 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 <greg.chab...@gmail.com> >> > > 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 <ta...@cservenak.net >> > >> > >> 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 >> > >> > >> > >> >> > > >> > >> >
