> On 25 May 2021, at 11:24, Dawid Weiss <dawid.we...@gmail.com > <mailto:dawid.we...@gmail.com>> wrote: > > > Ok. In that case we can make it simpler by not adding the signing plugin to > that (local) maven publication? Unless it makes sense to have it. Let me > know, this is a trivial change.
+1, that would be great. Thanks Dawid! On a different note, does gradle use the same configuration for when we do actual releases? I’m still confused as to why it wanted my GPG password in plaintext in a file somewhere. > > D. > > On Tue, May 25, 2021 at 8:36 AM Uwe Schindler <u...@thetaphi.de > <mailto:u...@thetaphi.de>> wrote: > Maven consumers only needs checksums to work correctly. The signatures are > optional. > > Uwe > > Am May 25, 2021 6:16:08 AM UTC schrieb Dawid Weiss <dawid.we...@gmail.com > <mailto:dawid.we...@gmail.com>>: > > These signatures are what makes a Maven repository a Maven repository though. > Even when you "deploy" to a local folder, it preserves the files required for > other Maven-toolchain tools. I'm not sure how it behaves without signatures. > > It is entirely doable to create a non-maven-task based assembly into a binary > distribution ZIP/ folder. Then no task exclusions will be required? > > Dawid > > On Mon, May 24, 2021 at 6:56 PM Uwe Schindler <u...@thetaphi.de > <mailto:u...@thetaphi.de>> wrote: > Thank for this tipp! Helps for Solr, too. I was giving up because it always > wanted to sign, that Jenkins can't easily do. > > Uwe > > Am May 24, 2021 8:03:51 AM UTC schrieb Alan Woodward <romseyg...@gmail.com > <mailto:romseyg...@gmail.com>>: > 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 >> <mailto: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/> > > > -- > 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/>
