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.
D. On Tue, May 25, 2021 at 8:36 AM Uwe Schindler <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 > >: >> >> >> 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> 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>: >>>> >>>> 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> >>>> 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> 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 >>>>> >: >>>>>> >>>>>> Jenkins does this already: >>>>>> 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 >>>>>> -Dversion.suffix=jenkins242 assemble >>>>>> >>>>>> Uwe >>>>>> >>>>>> Am May 20, 2021 12:25:48 PM UTC schrieb Michael Sokolov < >>>>>> 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> >>>>>>> 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 >>>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> Uwe Schindler >>>>>> Achterdiek 19, 28357 Bremen >>>>>> https://www.thetaphi.de >>>>> >>>>> >>>>> -- >>>>> Uwe Schindler >>>>> Achterdiek 19, 28357 Bremen >>>>> https://www.thetaphi.de >>>>> >>>>> >>>>> >>>> >>> -- >>> Uwe Schindler >>> Achterdiek 19, 28357 Bremen >>> https://www.thetaphi.de >>> >> > -- > Uwe Schindler > Achterdiek 19, 28357 Bremen > https://www.thetaphi.de >
