AFAIK m-gpg-p requires native gpg executable to work and is quite slow.
I think it would be better to have a java based default (e.g. bouncy-castle based).
Beside this as I recently came across this, will Signature SPI be accessible by other mojos so the can sign other artifacts as well without need of resolver? And will it be possible to konfirue this still in pom.xml?
I think your message indicates this but I'm not sure if I understand all this "knobs" things...
Am 07.12.22 um 12:59 schrieb Tamás Cservenák:
Howdy, To remove current impediments for the most anticipated Maven 4 feature, the "consumer POM", there was some discussion between Guillaume and me, and I'd like to share what we came up with. Current problem with (already working) feature is that it relies on FileTransformer API in resolver, but that API has several issues: - is OOM prone, hence is deprecated without replacement since Resolver 1.8.0, see https://issues.apache.org/jira/browse/MRESOLVER-244 - another issue is artifact signing, as that API above renders maven-pgp-plugin unusable (as what should be signed does not exists yet) Hence, to overcome these limitations, we agreed to: 1) Provide a replacement for FileTransformer API that does the same but is not OOM prone. This solves the OOM/deprecation side of things, but signing is not solved with it. As we know the signing issue is that transformation (with old but also with new API) happens "just in time" (just before install or deploy) in Resolver, outside of Maven realm, so is even further out of reach for any plugin. There were solutions like Slawek's sign plugin (https://github.com/s4u/sign-maven-plugin) that works with FileTransformer API, but from technical aspect (redoes what resolver already does) is fragile and mixes concerns IMHO. 2) As signing is somewhat very similar to checksumming (calculated and deployed by resolver on its own), we decided to take a stab on extending resolver with "Signature API" that is extensible with similar design as Checksum SPI (since 1.8.0 checksums have extensible SPI, one can easily introduce algorithm like xxhash to resolver). The OOTB signing "provider" will be based on existing maven-gpg-plugin code, essentially providing 100% the same feature that today's Maven 3.x + maven-gpg-plugin provides. Right now, the immediate goal is to achieve Maven 3 + m-gpg-p functionality (sign goal). Regarding "Signature SPI" (and provided GPG implementation) and it's use cases: - as signing would be from now provided by resolver, one could use "knobs" ( https://maven.apache.org/resolver/configuration.html) directly (ie `-Daether...`) to enable and configure it. Its effect would be that WHATEVER is uploaded thru Resolver Connector during the session, will be signed as well. - as next, the idea came up: we could modify m-gpg-p to provide "configuration" (knobs) via session into resolver, so "Signature API" would become active based on presence of these in session, hence, we would end up with literally same functionality and behaviour as today maven3 + m-gpg-p has (except that signing happens elsewhere), signing could be controlled by plugin per module basis. Related PRs for review (does not implement all this above, going "baby steps"): https://github.com/apache/maven-resolver/pull/227 https://github.com/apache/maven-resolver/pull/226 Example WIP PR to change Maven 4 to use new ArtifactTransform API: https://github.com/apache/maven/pull/904 (Remains in Robert's spirit while it does SAVE transformed POM, but into randomized temp file, and immediately is deleted once install/deploy is done). Any review, opinion and comment is welcome! Thanks T
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
