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 <ta...@cservenak.net> 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 <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 >>> > >> > >>> > >> >>> > > >>> > >>> >>
