Passing -x signJarsPublication skipped the signing step so I’m good to go. Thanks everyone for the help!
> On 23 May 2021, at 21:11, Dawid Weiss <dawid.we...@gmail.com> wrote: > > > Create a temporary pgp key for use with signing and use it to sign your maven > artifacts? I don't know if there is a way to use an agent - perhaps there is. > Hoss did some work with manual artifact signing recently (and this used the > agent). I never had the need for this. > > Dawid > > On Sat, May 22, 2021 at 4:50 PM Alan Woodward <romseyg...@gmail.com > <mailto:romseyg...@gmail.com>> wrote: > Passing -Dversion.suffix does indeed work, thanks Uwe! The next Yak to shave > is that gradle is now complaining that it can’t sign the artefacts. From my > reading it seems that I have to set things up in my gradle.properties file, > including my password in plain text. This seems … wrong? I don’t actually > need these artefacts signed anyway, so does anyone with more gradle-fu than > me know either a) how to skip the signing step or b) how to set things up so > that they are signed correctly without having my PGP password sitting in a > plain text file. > > Thanks! > >> On 20 May 2021, at 14:19, Uwe Schindler <u...@thetaphi.de >> <mailto:u...@thetaphi.de>> wrote: >> >> The default suffix in this system prop is "SNAPSHOT" and the timestamp comes >> then from Maven's internal Logic, this cannot be changed. >> >> By overriding the suffix explicit (as said before and find by Jenkins) you >> convert it to an official "release" in Maven's sense and it is no longer a >> snapshot. So you are free with versioning. >> >> Uwe >> >> Am May 20, 2021 1:15:12 PM UTC schrieb Uwe Schindler <u...@thetaphi.de >> <mailto:u...@thetaphi.de>>: >> Jenkins does this already: >> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/ >> <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/> >> >> It uses build number! >> >> The system property "version suffix" is responsible and is set by Jenkins. >> See in command line: [Lucene-Artifacts-main] $ >> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Artifacts-main/gradlew >> -Dlucene.javadoc.url=https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc >> <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc> >> -Dversion.suffix=jenkins242 assemble >> >> Uwe >> >> Am May 20, 2021 12:25:48 PM UTC schrieb Michael Sokolov <msoko...@gmail.com >> <mailto:msoko...@gmail.com>>: >> In principal it makes sense, but is there any chance the build artifact >> could vary for the same SHA? We hope not, I think, but stranger things have >> happened. Probably an edge case not worth worrying about though, and relying >> on the build server's clock doesn't seem great, so +1 from me, although I >> don't use these so my interest is mostly theoretical. >> >> On Thu, May 20, 2021, 8:20 AM Alan Woodward <romseyg...@gmail.com >> <mailto:romseyg...@gmail.com>> wrote: >> Hi all, >> >> I’m preparing a local lucene 9.0 snapshot build and I notice that the jar >> files generated by `./gradlew mavenToLocalFolder` are called something like >> `lucene-suggest-9.0.0-20210520.111833-1-javadoc.jar` - in other words, they >> are including a timestamp. For my setup I’d like to replace this with the >> git SHA of the commit the snapshot is based on. So I have two questions: >> >> 1) Is there a simple override or gradle property that I can pass on the >> command line that will change the output names of artefacts? >> 2) I think in general commit SHAs are better than timestamps for snapshot >> names - two identical snapshots taken from identical sources at different >> times shouldn’t really have different names. Should we look at changing the >> existing snapshot generation code to switch to using SHAs? >> >> - Alan >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> <mailto:dev-unsubscr...@lucene.apache.org> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> <mailto:dev-h...@lucene.apache.org> >> >> >> -- >> Uwe Schindler >> Achterdiek 19, 28357 Bremen >> https://www.thetaphi.de <https://www.thetaphi.de/> >> -- >> Uwe Schindler >> Achterdiek 19, 28357 Bremen >> https://www.thetaphi.de <https://www.thetaphi.de/>
