Maven 2.x and 3.x GPG Plugin

Allow option to create none ascii output

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.1
  • Fix Version/s: None
  • Environment:
    all
  • Number of attachments :
    0

Description

Please add new option "armor" with default value "true" to keep the default behavior.

The motivation is i am currently have a sh script using gpg and expect the produce a binary gpg file. It would be nice for me to use maven-gpg-plugin intead

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Bentmann added a comment -

And what's the use case driving the need for binary signatures? The existing plugin goals are meant to create signatures that get attached to the project for later installation/deployment. Are you just asking for a different format of these attachments (*.sig instead of *.asc) or is the general use case different?

Show
Benjamin Bentmann added a comment - And what's the use case driving the need for binary signatures? The existing plugin goals are meant to create signatures that get attached to the project for later installation/deployment. Are you just asking for a different format of these attachments (*.sig instead of *.asc) or is the general use case different?
Hide
Permalink
Dan Tran added a comment -

The motivation is just to support a legacy build which uses binary format and it is not easy to retrofit to assci format to existing customers. Keeping the same extension .asc will keep minimal change to gpg plugin

Show
Dan Tran added a comment - The motivation is just to support a legacy build which uses binary format and it is not easy to retrofit to assci format to existing customers. Keeping the same extension .asc will keep minimal change to gpg plugin
Hide
Permalink
Benjamin Bentmann added a comment -

So to double-check, your legacy build merely needs to deploy binary signatures along the project artifacts?

Keeping the same extension .asc will keep minimal change to gpg plugin

I don't think it's a good idea to mess with established conventions regarding the file extension and the implied content type. To my knowledge .sig is the extension usually used for binary signatures, so we should use that.

Show
Benjamin Bentmann added a comment - So to double-check, your legacy build merely needs to deploy binary signatures along the project artifacts? Keeping the same extension .asc will keep minimal change to gpg plugin I don't think it's a good idea to mess with established conventions regarding the file extension and the implied content type. To my knowledge .sig is the extension usually used for binary signatures, so we should use that.
Hide
Permalink
Dan Tran added a comment -

yes, I only have only one project, among many projects, that need this binary gpg signature deployed along with the build artifact.

Show
Dan Tran added a comment - yes, I only have only one project, among many projects, that need this binary gpg signature deployed along with the build artifact.
Hide
Permalink
Stephen Connolly added a comment -

I would rather see a separate parameter for creating the .sig files. The .asc files are required for deployment to central.

Something that the default is null/false, in which case no .sig files are generated, but if you specify the parameter as true, then the .sig files are generated in_addition_to the .asc files.

Show
Stephen Connolly added a comment - I would rather see a separate parameter for creating the .sig files. The .asc files are required for deployment to central. Something that the default is null/false, in which case no .sig files are generated, but if you specify the parameter as true, then the .sig files are generated in_addition_to the .asc files.

People

  • Assignee:
    Unassigned
    Reporter:
    Dan Tran
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: