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
