Signature files have wrong name when published via bintrayUpload

[robertpanzer]

When trying to promote the artifacts to Maven Central it complained about missing signature files.

It seems that they are renamed during upload for example from asciidoctorj-1.6.0-alpha.3.jar.asc to asciidoctorj-1.6.0-alpha.3-jar.asc and Maven Central does not like that.

The files in the local file system have the correct file name, e.g. asciidoctorj-1.6.0-alpha.3.jar.asc.

For the 1.6.0-alpha.3 release I uploaded them manually now.

[ancho]

Oh...that is sad.
The archives known to the bintray plugin seem totally fine.

configurations.archives.artifacts.each {
  println it.getFile()
}

asciidoctorj-core/build/libs/asciidoctorj-1.6.0-test.jar
asciidoctorj-core/build/libs/asciidoctorj-1.6.0-test.jar.asc
asciidoctorj-core/build/libs/asciidoctorj-1.6.0-test-sources.jar
asciidoctorj-core/build/libs/asciidoctorj-1.6.0-test-sources.jar.asc
asciidoctorj-core/build/libs/asciidoctorj-1.6.0-test-javadoc.jar
asciidoctorj-core/build/libs/asciidoctorj-1.6.0-test-javadoc.jar.asc

I shortened the paths for better readability. They are absolute and the ones you found in your filesystem.

But have a look at what the bintray plugin does:

(Dry run) Created version 'asciidoctor/maven/asciidoctorj/1.6.0-test'.
Uploading to https://api.bintray.com/content/asciidoctor/maven/asciidoctorj/1.6.0-test/org/asciidoctor/asciidoctorj/1.6.0-test/asciidoctorj-1.6.0-test.jar...
(Dry run) Uploaded to 'https://api.bintray.com/content/asciidoctor/maven/asciidoctorj/1.6.0-test/org/asciidoctor/asciidoctorj/1.6.0-test/asciidoctorj-1.6.0-test.jar'.
Uploading to https://api.bintray.com/content/asciidoctor/maven/asciidoctorj/1.6.0-test/org/asciidoctor/asciidoctorj/1.6.0-test/asciidoctorj-1.6.0-test-jar.asc...
(Dry run) Uploaded to 'https://api.bintray.com/content/asciidoctor/maven/asciidoctorj/1.6.0-test/org/asciidoctor/asciidoctorj/1.6.0-test/asciidoctorj-1.6.0-test-jar.asc'.

There is obviously a transformation going on. Maybe it's a feature but I don't get it.
I'll have a look. Maybe there is a bugreport or a bit of documentation how to configure it to make it work as expected.

[mojavelinux]

If I remember correctly, I had a difficult time getting this right when I first made the build. This was one of the reasons we had such a convoluted grouping of plugins, specifically the nebula plugins, because I was working around lots of bugs. I don't remember all the details now...I just remember it was incredibly difficult to get right.

[robertpanzer]

Filed bintray/gradle-bintray-plugin#124 for the gradle bintray plugin.

[ancho]

Thank you @robertpanzer for writing a bug report. I was too tired to do that.
Unfortunately it is not configurable by the plugin. See Artifact implementation. The "-$signedExtension" concatenation is the problem.

The nebula plugin will not help us in this case. The bintray plugin evolved too. We used the version 1.0.
The mapping to the Artifact class was introduced with 1.1.
Everybody seems to use the signing feature of bintray nowadays.

[mojavelinux]

Everybody seems to use the signing feature of bintray nowadays.

I'm in favor of that plan. It's definitely the direction we want to head.

[robertpanzer]

Sounds like a good idea.
Only thing that I am wondering is if it is possible to activate automatic signing only for one package instead of the whole Asciidoctor Maven archive in Bintray.
I am unsure if we can simply activate for all projects.

Another issue that I have is the security question: If I don't get it wrong anyone with Dan's, Alex's or my credentials could publish anything then.
At the moment to publish an AsciidoctorJ artifact signed by me requires my private key which is hopefully only on my machine.
With automatic signing the credentials should be sufficient to publish unless they have another 2FA solution in place.
(Or did I miss sth here?)

[mojavelinux]

Thanks to Ludovic, we've figured this one out. It's possible to create an SSH key, encrypt it and put it into the git repository for Travis to use. Only Travis will be able to unencrypt and use it. We should definitely look into setting that up for this repository. I can help.

See the following for reference:

• https://github.com/ldez/travis-continuous-delivery-atom-publish
• chore: continuous delivery atom-autocomplete-asciidoc#2

[robertpanzer]

Euh, maybe I am not understanding this correctly, but would that work?
We would still have the gradle bintray plugin upload the signatures when delegating the build to Travis.

I thought the idea was to upload the archives without signatures and let Bintray sign them (Hopefully with the correct file names) and then publish to Maven Central.

But I really have no experience with this yet, so I could be totally wrong.

I'll play with it over the next days with a private repo and see how it works (stopping at promoting anything to Maven Central certainly ;-) )

[mojavelinux]

I don't have it all sorted out in my head either. But my point is that there is now a way in Travis to get the user running the build to be authenticated (either through SSH or other means) so the build user has full permission to do what it needs to do.

[robertpanzer]

Seems like the issue will be fixed in version 1.7 of the gradle-bintray-plugin :-)
(See bintray/gradle-bintray-plugin#124 )