Mailing List Archive

Lucene 9.0 snapshot names
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <romseygeek@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <msokolov@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 <romseygeek@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <uwe@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
><msokolov@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 <romseygeek@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>
>--
>Uwe Schindler
>Achterdiek 19, 28357 Bremen
>https://www.thetaphi.de

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <uwe@thetaphi.de <mailto:uwe@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 <uwe@thetaphi.de <mailto:uwe@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 <msokolov@gmail.com <mailto:msokolov@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 <romseygeek@gmail.com <mailto:romseygeek@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-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@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/>
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <romseygeek@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 <uwe@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 <uwe@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 <
>> msokolov@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 <romseygeek@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de
>
>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de
>
>
>
Re: Lucene 9.0 snapshot names [ In reply to ]
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.weiss@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 <romseygeek@gmail.com <mailto:romseygeek@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 <uwe@thetaphi.de <mailto:uwe@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 <uwe@thetaphi.de <mailto:uwe@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 <msokolov@gmail.com <mailto:msokolov@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 <romseygeek@gmail.com <mailto:romseygeek@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-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@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/>
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <romseygeek@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.weiss@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 <romseygeek@gmail.com
><mailto:romseygeek@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 <uwe@thetaphi.de
><mailto:uwe@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
><uwe@thetaphi.de <mailto:uwe@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
><msokolov@gmail.com <mailto:msokolov@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 <romseygeek@gmail.com
><mailto:romseygeek@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-unsubscribe@lucene.apache.org
><mailto:dev-unsubscribe@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org
><mailto:dev-help@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
Re: Lucene 9.0 snapshot names [ In reply to ]
Sounds like this would be a good addition to /dev-docs/...

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Mon, May 24, 2021 at 12:56 PM Uwe Schindler <uwe@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 <romseygeek@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.weiss@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 <romseygeek@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 <uwe@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 <uwe@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 <
>>>> msokolov@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 <romseygeek@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@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
>
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <uwe@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 <romseygeek@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.weiss@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 <romseygeek@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 <uwe@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 <uwe@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 <
>>>> msokolov@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 <romseygeek@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@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
>
Re: Lucene 9.0 snapshot names [ In reply to ]
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.weiss@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 <uwe@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
><romseygeek@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.weiss@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 <romseygeek@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 <uwe@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
><uwe@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 <
>>>>> msokolov@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
><romseygeek@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-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@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
Re: Lucene 9.0 snapshot names [ In reply to ]
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 <uwe@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.weiss@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 <uwe@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 <
>>> romseygeek@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.weiss@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 <romseygeek@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 <uwe@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 <uwe@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 <
>>>>>> msokolov@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 <romseygeek@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-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@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
>
Re: Lucene 9.0 snapshot names [ In reply to ]
> On 25 May 2021, at 11:24, Dawid Weiss <dawid.weiss@gmail.com <mailto:dawid.weiss@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 <uwe@thetaphi.de <mailto:uwe@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.weiss@gmail.com <mailto:dawid.weiss@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 <uwe@thetaphi.de <mailto:uwe@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 <romseygeek@gmail.com <mailto:romseygeek@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.weiss@gmail.com <mailto:dawid.weiss@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 <romseygeek@gmail.com <mailto:romseygeek@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 <uwe@thetaphi.de <mailto:uwe@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 <uwe@thetaphi.de <mailto:uwe@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 <msokolov@gmail.com <mailto:msokolov@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 <romseygeek@gmail.com <mailto:romseygeek@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-unsubscribe@lucene.apache.org <mailto:dev-unsubscribe@lucene.apache.org>
>>> For additional commands, e-mail: dev-help@lucene.apache.org <mailto:dev-help@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/>
Re: Lucene 9.0 snapshot names [ In reply to ]
> 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.
>

I don't think we've done a proper release with gradle workflow. I can't
remember doing much in that area - it should be the "packaging" project
that does proper distribution assembly (and signing). And maven artifacts
(that you used) are currently collected using a different route.

Dawid