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 >
[ANN] Apache Maven GPG Plugin 3.2.2 Released
Howdy, The Apache Maven team is pleased to announce the release of the Apache Maven GPG Plugin, version 3.2.2 This release is a bugfix, restoring the sign-and-deploy Mojo to pick up remote repository authentication from settings.xml. Also contains smaller improvements as well. This plugin signs all of the project's attached artifacts with GnuPG or BC. https://maven.apache.org/plugins/maven-gpg-plugin/ You should specify the version in your project's plugin configuration: org.apache.maven.plugins maven-gpg-plugin 3.2.2 You can download the appropriate sources etc. from the download page: https://maven.apache.org/plugins/maven-gpg-plugin/download.cgi Release Notes - Maven GPG Plugin - Version 3.2.2 ** Bug * [MGPG-113] - Upgrading from 3.1.0 to 3.2.1 with no other changes causes "gpg:sign-and-deploy-file" failed: 401 Unauthorized ** Improvement * [MGPG-114] - BC Allow key size greater than 5KB from file * [MGPG-115] - Show more information about key used to sign Have fun, -The Apache Maven team
