The maven pattern for sbt plugins is invalid based on the spec

I’ve been in touch with the Bintray team because of https://github.com/sbt/sbt-bintray/pull/125.

It happens that the reason why sbt bintray does not accept the fix in the aforementioned PR is because sbt has been using an incorrect Maven pattern for sbt plugins. This is the reply I got from the Bintray team:

Going off of the Maven Design Documentation, Bintray expects the following Maven layout format: [orgPath]/[module]/[baseRev](-[folderItegRev])/[module]-[baseRev](-[fileItegRev])(-[classifier]).[ext]. Note the “module” field appears twice.

Our pattern is the following: https://github.com/sbt/librarymanagement/blob/53c80f076a5e9ab469037f352a4d68173140e216/core/src/main/scala/sbt/librarymanagement/ResolverExtra.scala#L357-L358, which is obviously wrong (there’s a concept of module and a concept of artifact, where both should be the same).

The reason why this works for Sonatype is because they have a permissive layout for projects whose publishing rules do not abide by the spec. Bintray doesn’t, and that’s why no one has succeeded to publish sbt plugins to Bintray maven repositories.

This is a major issue that IMO should be sorted out as soon as possible. The only way I see to solve this problem is to add another pattern to sbt and make it use alongside the wrong pattern (we cannot remove it, too many projects depend on it).

[eed3si9n]

Now that we’re telling people to use Maven Central for sbt plugins, we should really fix this for sbt 2.x.

[jvican]

In practice it should not be a problem because the majority of the plugin ecosystem is on Ivy layout that we host.

This is not true. Lots of plugins publish to Sonatype, and there’s no reason why sbt should force its ecosystem to live in a platform (Bintray) where at the moment you use too many resources you have to pay, and that has given us several problems in the past (remember when people were not able to fetch sbt two months ago during one week?).

This is, to some degree an intentional design because Maven doesn’t have the notion of extra attribute that we can use as resolution axis

To me, it seems this problem could have been solved if we had used the following pattern: "[organisation]/[module](_[scalaVersion])(_[sbtVersion])/[revision]/[module](_[scalaVersion])(_[sbtVersion])-[revision](-[classifier]).[ext]" only for sbt plugins, instead of trying to reuse it.