Publishing to Sonatype via SBT

Question

I am attempting to publish a scala library to the OSS Sonatype repository via SBT. I have followed the SBT guides for Publishing0 & Using Sonatype and reviewed the Sonatype requirements documentation, but cannot seem to publish my artifacts. All attempts end with java.io.IOException: Access to URL [...] was refused by the server: Forbidden. I have had the necessary repository setup done in the Sonatype JIRA system. I have created a PGP key and published it to hkp://pool.sks-keyservers.net & hkp://keyserver.ubuntu.com.

build.sbt

import play.twirl.sbt.SbtTwirl

name := "spring-mvc-twirl"

organization := "us.hexcoder"

version := "1.0.0-SNAPSHOT"

scalaVersion := "2.11.2"

sbtVersion := "0.13.5"

lazy val root = (project in file(".")).enablePlugins(SbtTwirl)

// Removed for brevity    
libraryDependencies ++= Seq()

// Test dependencies
// Removed for brevity
libraryDependencies ++= Seq()

// Publish configurations
publishMavenStyle := true

publishArtifact in Test := false

publishTo := {
    val nexus = "https://oss.sonatype.org/"
    if (isSnapshot.value)
        Some("snapshots" at nexus + "content/repositories/snapshots")
    else
        Some("releases"  at nexus + "service/local/staging/deploy/maven2")
}

licenses := Seq("MIT" -> url("http://opensource.org/licenses/MIT"))

homepage := Some(url("https://github.com/67726e/Spring-MVC-Twirl"))

credentials += Credentials(Path.userHome / ".sbt" / ".credentials")

pomIncludeRepository := { _ => false }

// Additional POM information for releases
pomExtra :=
<developers>
    <developer>
        <name>Glenn Nelson</name>
        <email>[email protected]</email>
    </developer>
</developers>
<scm>
    <connection>scm:git:[email protected]:67726e/Spring-MVC-Twirl.git</connection>
    <developerConnection>scm:git:[email protected]:67726e/Spring-MVC-Twirl.git</developerConnection>
    <url>[email protected]:67726e/Spring-MVC-Twirl.git</url>
</scm>

SBT Output:

> publishSigned
[info] Wrote /Users/67726e/Documents/Spring-MVC-Twirl/target/scala-2.11/spring-mvc-twirl_2.11-1.0.0-SNAPSHOT.pom
[info] :: delivering :: us.hexcoder#spring-mvc-twirl_2.11;1.0.0-SNAPSHOT :: 1.0.0-SNAPSHOT :: integration :: Tue Aug 19 09:57:13 EDT 2014
[info]  delivering ivy file to /Users/67726e/Documents/Spring-MVC-Twirl/target/scala-2.11/ivy-1.0.0-SNAPSHOT.xml
[trace] Stack trace suppressed: run last *:publishSigned for the full output.
[error] (*:publishSigned) java.io.IOException: Access to URL https://oss.sonatype.org/content/repositories/snapshots/us/hexcoder/spring-mvc-twirl_2.11/1.0.0-SNAPSHOT/spring-mvc-twirl_2.11-1.0.0-SNAPSHOT-sources.jar was refused by the server: Forbidden
[error] Total time: 5 s, completed Aug 19, 2014 9:57:18 AM
> last *:publishSigned
java.io.IOException: Access to URL https://oss.sonatype.org/content/repositories/snapshots/us/hexcoder/spring-mvc-twirl_2.11/1.0.0-SNAPSHOT/spring-mvc-twirl_2.11-1.0.0-SNAPSHOT-sources.jar was refused by the server: Forbidden
    at org.apache.ivy.util.url.AbstractURLHandler.validatePutStatusCode(AbstractURLHandler.java:79)
    at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:264)
    at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150)
    at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84)

Answer 1

As it turns out, this is one of those rare times as a developer where the issue is not in any way caused by me. I filed a JIRA ticket on the Sonatype tracker and it turns out there was an with their tooling that caused my account to have not been granted the correct permissions during provisioning.

To address @MikeAllen's comments, I had already created a JIRA account and had my repository created by filing a JIRA ticket as a part of their workflow (this was done 5 days prior). The directory corresponding to my domain/group of hexcoder.us - us/hexcoder was not created until I pushed my first snapshot as seen by the timestamps in the directory browser. It does not appear to be created during repository provisioning.

Finally, I wholly believe that performing one's due diligence is a necessity when it comes to investigating and debugging errors. However do not take it to the extreme as I often do and neglect to ask for assistance from others after a reasonable amount of time has been spent.