Mailing List Archive

I remember using a 8.x build to do that for the 9.0 release.

On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:

>
> I looked at an old issue related to maven artifact publishing and I
> noticed the release wizard still gives instructions to use the ant-based
> script (which isn't there anymore?):
>
> ant clean stage-maven-artifacts
>
> I'm sorry to ask but how did release managers stage maven artifacts so far
> on 9x?
>
> Dawid
>


--
Adrien

Yeah, I thought so. I'd love to help improve this as part of the next
release - it should really be simple. I know the old way was to have maven
artifacts separately (to agree/vote upon) but in my opinion it wouldn't
change much if the release manager pointed to release artifacts + maven
artifact (staging) repository uploaded to Apache Nexus. Those are browsable
and artifacts can be downloaded from there before voting (although I'm not
sure if anybody inspects those maven artifacts). Also, the staging
repository can "hang" unreleased until the voting is closed. This would
make the build side of things much easier and wound't require any extra
infrastructure/ steps.

Dawid

On Thu, Nov 17, 2022 at 2:08 PM Adrien Grand <jpountz@gmail.com> wrote:

> I remember using a 8.x build to do that for the 9.0 release.
>
> On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
>>
>> I looked at an old issue related to maven artifact publishing and I
>> noticed the release wizard still gives instructions to use the ant-based
>> script (which isn't there anymore?):
>>
>> ant clean stage-maven-artifacts
>>
>> I'm sorry to ask but how did release managers stage maven artifacts so
>> far on 9x?
>>
>> Dawid
>>
>
>
> --
> Adrien
>

I remember another proposal which consisted of using the Gradle build to
rebuild Maven artifacts at the type of uploading to Nexus, which I liked
less because it involved re-building, and who knows what may happen that
could produce slightly different binaries. I like your new proposal better.

> Those are browsable and artifacts can be downloaded from there before
voting (although I'm not sure if anybody inspects those maven artifacts)

I suspect you know this, but the smoke tester does download these artifacts
and runs some checks.



On Thu, Nov 17, 2022 at 2:31 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:

>
> Yeah, I thought so. I'd love to help improve this as part of the next
> release - it should really be simple. I know the old way was to have maven
> artifacts separately (to agree/vote upon) but in my opinion it wouldn't
> change much if the release manager pointed to release artifacts + maven
> artifact (staging) repository uploaded to Apache Nexus. Those are browsable
> and artifacts can be downloaded from there before voting (although I'm not
> sure if anybody inspects those maven artifacts). Also, the staging
> repository can "hang" unreleased until the voting is closed. This would
> make the build side of things much easier and wound't require any extra
> infrastructure/ steps.
>
> Dawid
>
> On Thu, Nov 17, 2022 at 2:08 PM Adrien Grand <jpountz@gmail.com> wrote:
>
>> I remember using a 8.x build to do that for the 9.0 release.
>>
>> On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss <dawid.weiss@gmail.com>
>> wrote:
>>
>>>
>>> I looked at an old issue related to maven artifact publishing and I
>>> noticed the release wizard still gives instructions to use the ant-based
>>> script (which isn't there anymore?):
>>>
>>> ant clean stage-maven-artifacts
>>>
>>> I'm sorry to ask but how did release managers stage maven artifacts so
>>> far on 9x?
>>>
>>> Dawid
>>>
>>
>>
>> --
>> Adrien
>>
>

--
Adrien

> I remember another proposal which consisted of using the Gradle build to
> rebuild Maven artifacts at the type of uploading to Nexus, which I liked
> less because it involved re-building, and who knows what may happen that
> could produce slightly different binaries. I like your new proposal better.
>

Right - it would have to be a one-step operation, otherwise I wouldn't bet
on those JARs being the same...


> > Those are browsable and artifacts can be downloaded from there before
> voting (although I'm not sure if anybody inspects those maven artifacts)
>
> I suspect you know this, but the smoke tester does download these
> artifacts and runs some checks.
>

We could still build that zip for the smoke tester. The important thing
here is that local artifact building and staged artifacts would be synced
(uploaded within one gradle command).

An alternative is to implement post-vote artifact upload in gradle (or ant
within gradle). This is also possible but seems somewhat backward...

Dawid

>

I think, if smoke tester knows the version, it could just check the
staging repo, too. It is just another URL!? If the staging repository on
nexus has a hash inside (I think they have), maybe the release wizard
places some file with the URL of the actual staging repo into the folder?

Uwe

Am 17.11.2022 um 14:37 schrieb Adrien Grand:
> I remember another proposal which consisted of using the Gradle build
> to rebuild Maven artifacts at the type of uploading to Nexus, which I
> liked less because it involved re-building, and who knows what may
> happen that could produce slightly different binaries. I like your new
> proposal better.
>
> > Those are browsable and artifacts can be downloaded from there
> before voting (although I'm not sure if anybody inspects those maven
> artifacts)
>
> I suspect you know this, but the smoke tester does download these
> artifacts and runs some checks.
>
>
>
> On Thu, Nov 17, 2022 at 2:31 PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
>
> Yeah, I thought so. I'd love to help improve this as part of the
> next release - it should really be simple. I know the old way was
> to have maven artifacts separately (to agree/vote upon) but in my
> opinion it wouldn't change much if the release manager pointed to
> release artifacts + maven artifact (staging) repository uploaded
> to Apache Nexus. Those are browsable and artifacts can be
> downloaded from there before voting (although I'm not sure if
> anybody inspects those maven artifacts). Also, the staging
> repository can "hang" unreleased until the voting is closed. This
> would make the build side of things much easier and wound't
> require any extra infrastructure/ steps.
>
> Dawid
>
> On Thu, Nov 17, 2022 at 2:08 PM Adrien Grand <jpountz@gmail.com>
> wrote:
>
> I remember using a 8.x build to do that for the 9.0 release.
>
> On Thu, Nov 17, 2022 at 1:54 PM Dawid Weiss
> <dawid.weiss@gmail.com> wrote:
>
>
> I looked at an old issue related to maven artifact
> publishing and I noticed the release wizard still gives
> instructions to use the ant-based script (which isn't
> there anymore?):
>
> ant clean stage-maven-artifacts
>
> I'm sorry to ask but how did release managers stage maven
> artifacts so far on 9x?
>
> Dawid
>
>
>
> --
> Adrien
>
>
>
> --
> Adrien

--
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail:uwe@thetaphi.de

> I think, if smoke tester knows the version, it could just check the staging repo, too. It is just another URL!?

Yes, it's an URL.

> If the staging repository on nexus has a hash inside (I think they have), maybe the release wizard places some file with the URL of the actual staging repo into the folder?

I spent some time digging. I am no longer convinced direct Nexus
staging would be a good thing to do because you can have multiple
staging repos (from multiple rcs) and accidentally release the wrong
one - a step from which there's no recovery...

The staging API for Nexus is quite simple - Solr's upload-maven.sh has
almost all of it covered (the exception being profile ID retrieval).
Unsurprisingly, Nexus API is documented in a terrible way and lacks
the documentation
for the key staging method (deployByRepositoryId)...

https://oss.sonatype.org/nexus-staging-plugin/default/docs/index.html

I'll write that nexus-pushing script, no problem there. I'm just
looking at options other than bash + curl because this seems rather
crude. All the pieces are in place though, it's downhill now.


Dawid

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org