Resolve file validation errors blocking deployment of first version

[Andrapyre]

Description

Sonatype Central is having problems correctly validating sbt plugins. A normal publish command for a non-plugin repo will eventually output a directory with a set of files, all of which start with <package_name>_<scala_version>-<package_version>.

Example: A package like the sonatype central client contains the following files.

Sbt plugins, however, follow a different structure containing a set of files that only start with <package_name>-<package_version> alongside files that start with the standard <package_name>_<scala_version>-<package_version>.

Example: A package like the sbt release plugin contains the following files.

Sonatype Central is reporting errors for all files that lack the scala version.

Reproduce Problem

To reproduce, run the following steps:

1. Clone sbt release or any sbt plugin with the pgp plugin installed. Ensure that any build prerequisites are installed.
2. Run sbt publishSigned.
3. Manually zip and upload the contents of ./target/sonatype-staging/<version>/ to Sonatype Central (in the case of sbt-release, com should be the first directory in the resultant zip bundle).
4. You should see that half the files have validation errors.

[Andrapyre]

@eed3si9n or @SethTisue, maybe one of you has an idea for a workaround? For long-term, should this be fixed from the sbt side or should we contact sonatype support and ask them to change their validation?

[eed3si9n]

Not sure if you're running into the same issue but @adpi2 implemented POM consistency in sbt 1.9.0 - https://eed3si9n.com/sbt-1.9.0

Also if sbt-sonatype can already publish things. Does this plugin use a different API?

[Andrapyre]

Interesting. Both sbt-release and this plugin are using the latest versions of sbt, so, if POM consistency was merged in 1.9.0, it shouldn't be that, but I will take a look.

Sonatype Central is a new portal with a totally different publishing api that will be the future way to publish new packages to Maven Central. Users were already required to use the new portal if they didn't have an account with Sonatype as of Feb. 1st, 2024 (though I think they ended up pushing that date back by a few weeks/months).

I integrated this functionality into mill and tried to integrate it into sbt-sonatype, but in both places I received the feedback that it should be kept completely seperate from the old functionality, since the publishing process is too different. In mill we did it with a separate contrib module and with sbt we'll need to it with a separate plugin.

See these PRs for context:
xerial/sbt-sonatype#474

com-lihaoyi/mill#3130

[Andrapyre]

@eed3si9n , a further question - is the second set of files (without the scala version) needed? Or are they necessary for some legacy functionality that I don't know about? If they're definitely not necessary, then I will just manually delete them, so that I can get the first version of this out.

[eed3si9n]

@adpi2 would know more, but the existence of coursier/coursier#2633 might mean that if you dropped POM-inconsistent style (controlled via sbtPluginPublishLegacyMavenStyle), the build users might be forced to use sbt 1.9.x and up?

[adpi2]

a further question - is the second set of files (without the scala version) needed? Or are they necessary for some legacy functionality that I don't know about?

They are only needed by sbt < 1.9.x, to resolve plugins using the old pattern. After 1.9, sbt first tries to resolve with the new pattern.

If they're definitely not necessary, then I will just manually delete them, so that I can get the first version of this out.

There is a settings to stop generating them: https://github.com/sbt/sbt/blob/586e0a752cd5d0f0335deaa910c4355e0e0a0e56/main/src/main/scala/sbt/Keys.scala#L500C7-L500C39

Maybe you're plugin should override the default of that setting.

[Andrapyre]

Ok, setting sbtPluginPublishLegacyMavenStyle to false in #5 fixed this and we now have the first working version out. Thanks to both of you!

One last question - what are the next steps around deploying plugins? Currently, it looks like it's not possible to deploy plugins in the new Sonatype Central Portal that will work with sbt versions prior to 1.9.x. Should we contact them to ask them to change their validation or is their another plan for making newer sbt plugins backwards compatible (like an additional plugin for backwards compat - not sure how feasible that is)?

[adpi2]

Sonatype Central is a new portal with a totally different publishing api that will be the future way to publish new packages to Maven Central. Users were already required to use the new portal if they didn't have an account with Sonatype as of Feb. 1st, 2024 (though I think they ended up pushing that date back by a few weeks/months).

As long as old plugins can still publish using the legacy style, I think it is okay if we force everybody else (new plugins) to publish with the new pattern only. Also in sbt 2.x I don't plan on keeping the legacy style, even for publishing sbt 1.x plugins.

like an additional plugin for backwards compat - not sure how feasible that is?

Maybe it could work, but I am not sure if it is worth it.

[Andrapyre]

@adpi2 , sorry for the delay in response. So that's the issue - old plugins in the legacy style cannot currently be published to Sonatype Central, as they are flagged in the validation process.