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