-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature - allow signing to be specified in settings.xml #50
base: master
Are you sure you want to change the base?
Feature - allow signing to be specified in settings.xml #50
Conversation
…~/m2/settings.xml
7172492
to
792e01c
Compare
Thanks for the PR. This makes total sense. There are a few "style" comments I will add, I hope you don't mind 😀 I am just wondering, should it already be possible to configure the via properties using |
import java.util.Map; | ||
import java.util.Optional; | ||
import java.util.Set; | ||
import java.util.*; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer to have expanded imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay sure. Apologies, my IDE (IntelliJ) insists on doing these automated "improvements" for me.
* The signing variables are: keyId, keyringFile, passphrase, hashAlgorithm. | ||
*/ | ||
@Parameter(defaultValue = "rpm.") | ||
private String signCfgPrefix; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer a non-abbreviated name, e.g. signConfigurationPrefix
. And wouldn't it make sense to allow the user to set this via properties as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can certainly do that. I just took the existing syntax from jdeb, but I can update it...
@@ -785,6 +796,47 @@ public void execute () throws MojoExecutionException, MojoFailureException | |||
provider.apply ( builder ); | |||
} | |||
|
|||
// load any default signing properties from settings.xml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe wrap this section up in another method?
return Collections.emptyMap(); | ||
} | ||
|
||
final Map<String, String> map = new HashMap<String, String>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC we are on Java 8. So you can drop the type arguments on the constructor:
final Map<String, String> map = new HashMap<String, String>(); | |
final Map<String, String> map = new HashMap<>(); |
} | ||
|
||
final Map<String, String> map = new HashMap<String, String>(); | ||
final Set<String> activeProfiles = new HashSet<String>(activeProfilesList); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
final Set<String> activeProfiles = new HashSet<String>(activeProfilesList); | |
final Set<String> activeProfiles = new HashSet<>(activeProfilesList); |
Re-iterating over the PR, wouldn't it be possible to find a solution which doesn't require to manually iterate over the settings and profiles? |
@ctron I did actually try such an approach first but I could not get it to work, which is why we ended up with iterating over the properties. |
@ctron I pushed a commit which I think addresses your comments. |
I kind of wonder why it can't use the existing gpg properties (described here) for this (although I understand why you might want different ones). I guess putting it in settings has transparent support for encrypted passwords? I don't really see the point in making the prefix configurable as all the other properties using an |
I tend to agree here. Making it configurable, may sound nice for some niche use cases, but adds some complexity that I am not sure, is worth it. I completely understand the use case, but would prefer something that works without manually iterating over the settings. |
I did a quick check: Using the properties from @Mojo(name = "sayhi")
public class MyMojo extends AbstractMojo {
@Parameter(property = "project", readonly = true, required = true)
private MavenProject project;
@Parameter(property = "session", readonly = true, required = true)
private MavenSession session;
@Override
public void execute() throws MojoExecutionException {
Properties p = new Properties();
p.putAll(project.getProperties());
p.putAll(session.getSystemProperties());
p.putAll(session.getUserProperties());
for ( Map.Entry<?, ?> entry : p.entrySet()) {
getLog().info(String.format("%-40s: %s", entry.getKey(), entry.getValue()));
}
}
} |
Any chance for this to be merged? It looks like a nice improvement over configuring signing inside the pom.xml |
This PR takes a feature from jdeb which allows the signing information to be specified in an active profile within
~/.m2/settings.xml
.This makes configuring the plugin for externalising the sensitive signature config options simpler, as custom property names no longer have to be explicitly specified in the pom.xml. Of course you can still specify custom property names if you wish ;-)
Simply adding the following to your your
~/.m2/settings.xml
should be enough:The
rpm.
prefix of the property names can be customised through the plugin configuration elementsignCfgPrefix