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
