Jackson 2.10.0 release starting -- severe problems with Sonatype OSS repository

[Tatu Saloranta]

So: I tried to start pushing Jackson 2.10.0 release, but Sonatype's
Open Source Nexus repository (OSSRH) seems to have some serious issues
unfortunately. While I will try to get these resolved it looks like:

1. 2.10.0 release will take longer, possible more than 24 hours
2. During this time, some versions visible via Maven Central may
actually be corrupt

Specifically, `jackson-annotations` release seems to be somehow
corrupt. I will try to get that rectified, but until then, please do
not use version 2.10.0 of Jackson components.

-+ Tatu +-

[Brian Devins-Suresh]

Hi Tatu,

I saw that you have partially resolved this issue, could you share what steps you took to fix it?

We have run into a similar problem on the Zipkin project with the last library release we attempted 

so any input would be greatly appreciated.

Thanks!

Brian

[Tatu Saloranta]

On Fri, Sep 27, 2019 at 12:31 PM Brian Devins-Suresh <bade...@gmail.com> wrote:
>
> Hi Tatu,
>
> I saw that you have partially resolved this issue, could you share what steps you took to fix it?
>
> We have run into a similar problem on the Zipkin project with the last library release we attempted
> so any input would be greatly appreciated.

Sorry to hear that!

I filed this issue:

https://issues.sonatype.org/browse/OSSRH-51881

and Joel (who is very responsive, good person to get help from) just
resolved it an hour ago.

I think that the way I usually try to resolve problems is to:

1. First retry Nexus UI operation (close or release) as those can fail
transiently
2. If failure is not transient, try release (via Maven release plug-in
or whatever your workflow is) again, then Nexus UI. Sometimes this
seems to work, update incomplete release artifact set
3. If (2) fails, file OSSRH issue. In this case repository was
"locked", I think, so admin override was needed

I also think that at this point I will need to go back and really
learn how to use Sonatype's Nexus plug-in:

https://blog.sonatype.com/maven-deploy-to-nexus

as it should be more reliable mechanism for making releases (and
possible more convenient).

Hope this helps!

-+ Tatu +-

>
> Thanks!
> Brian
>
> On Thursday, September 26, 2019 at 12:11:43 AM UTC-4, Tatu Saloranta wrote:
>>
>> So: I tried to start pushing Jackson 2.10.0 release, but Sonatype's
>> Open Source Nexus repository (OSSRH) seems to have some serious issues
>> unfortunately. While I will try to get these resolved it looks like:
>>
>> 1. 2.10.0 release will take longer, possible more than 24 hours
>> 2. During this time, some versions visible via Maven Central may
>> actually be corrupt
>>
>> Specifically, `jackson-annotations` release seems to be somehow
>> corrupt. I will try to get that rectified, but until then, please do
>> not use version 2.10.0 of Jackson components.
>>
>> -+ Tatu +-
>

> --
> You received this message because you are subscribed to the Google Groups "jackson-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jackson-user...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-user/813d696c-632a-4937-9295-3ca8e568c5ae%40googlegroups.com.

[Steinar Bang]

>>>>> Tatu Saloranta <ta...@fasterxml.com>:

> I also think that at this point I will need to go back and really
> learn how to use Sonatype's Nexus plug-in:

> https://blog.sonatype.com/maven-deploy-to-nexus

> as it should be more reliable mechanism for making releases (and
> possible more convenient).

FWIW These projects contain config for maven-release-plugin and
nexus-staging-maven-plugin that has let me successfully deploy to OSSRH
with "mvn release:prepare" and "mvn release:perform". I arrived at them
with a lot of broken deploys and increment of minor version numbers:
https://github.com/steinarb/authservice/blob/master/pom.xml#L567
https://github.com/steinarb/sonar-collector/blob/master/pom.xml#L365

When a release work I just do (swap the version numbers with the actual
versions used. developmentVersion is the next snapshot version after the
release):
mvn release:prepare -DautoVersionSubmodules=true -DdevelopmentVersion=1.6.0-SNAPSHOT -DreleaseVersion=1.5.3
mvn release:perform
and an unspecified time after "release:perform" completes (but less than
24h) the artifacts are available from maven central.

(however when/if they break I usually have no idea what went wrong, and
just have to try again. The last couple of times a relase have failed I
have rolled back the release, scrubbed the commits made by
maven-release-plugin, force pushed the change to the remote (github) and
deleted the release tag both locally and on the remote, and then run
"mvn release:prepare" and "mvn release:perform" again and this time it
has gone through)

[Tatu Saloranta]

On Sun, Oct 6, 2019 at 2:24 AM Steinar Bang <s...@dod.no> wrote:
>
> >>>>> Tatu Saloranta <ta...@fasterxml.com>:
>
> > I also think that at this point I will need to go back and really
> > learn how to use Sonatype's Nexus plug-in:
>
> > https://blog.sonatype.com/maven-deploy-to-nexus
>
> > as it should be more reliable mechanism for making releases (and
> > possible more convenient).
>
> FWIW These projects contain config for maven-release-plugin and
> nexus-staging-maven-plugin that has let me successfully deploy to OSSRH
> with "mvn release:prepare" and "mvn release:perform". I arrived at them
> with a lot of broken deploys and increment of minor version numbers:
> https://github.com/steinarb/authservice/blob/master/pom.xml#L567
> https://github.com/steinarb/sonar-collector/blob/master/pom.xml#L365

Thank you for sharing these!

> When a release work I just do (swap the version numbers with the actual
> versions used. developmentVersion is the next snapshot version after the
> release):
> mvn release:prepare -DautoVersionSubmodules=true -DdevelopmentVersion=1.6.0-SNAPSHOT -DreleaseVersion=1.5.3
> mvn release:perform
> and an unspecified time after "release:perform" completes (but less than
> 24h) the artifacts are available from maven central.

Ok. Sounds similar to my use of release plugin (although I hadn't
thought of passing new version via command-line switch, makes sense).

> (however when/if they break I usually have no idea what went wrong, and
> just have to try again. The last couple of times a relase have failed I
> have rolled back the release, scrubbed the commits made by
> maven-release-plugin, force pushed the change to the remote (github) and
> deleted the release tag both locally and on the remote, and then run
> "mvn release:prepare" and "mvn release:perform" again and this time it
> has gone through)

Ah. That is similar to what happens with default deploy plug-in I suppose,

-+ Tatu +-