:roadmap:uploadArchivesUploading: com/optrak/roadmap/roadmap/2.3.429/roadmap-2.3.429.jar to repository remote at http://libra.office.optrak.com:8080/nexus/content/repositories/releases
Transferring 2350K from remote
Error writing to server
FAILED
The repository requires authentication to write but not to read. I had a similar issue with some of my own code where the problem was the use of streaming for the upload. This prevents automatic handling of authentication. Possible solutions are either preemptive authentication, or upload a small file first (e.g. a POM or even the SHA1 hash) without streaming. Once authentication is established it will continue to be used for subsequent uploads.
This problem was encountered with Gradle 2.0.
Are you configuring credentials for your repository in the build script? We preemptively send credentials on all PUT and POST requests.
Yes, the credentials are configured but the server logs show no evidence of them being used on the failing request, though they are used on a later upload in the same build.
Can you perhaps share how you are configuring publishing in your build script?
upload.configure {
repositories {
mavenDeployer {
repository(url: "${nexusURL}/content/repositories/"+targetRepository) {
authentication(userName: nexusUser, password: nexusPassword)
}
pom.whenConfigured {
p->getPomVersionEditor(project).editPom(project, p)
}
uniqueVersion = false
}
}
// configure tests for up to date
onlyIf {doUpload}
doFirst(new ArtifactsUpToDateAction(uploadedVersions));
doLast(uploadedVersions)
}
The “old” publishing mechanism delegates to the Maven Wagon implementation. I’m not sure if they preemptively authenticate or not. That said, the server should return a 401 indicating authentication is required. We only preemptively send credentials for performance reasons.
An option might be to try the ‘maven-publish’ plugin which does preemptively send credentials on writes.
I note that the new maven-publish is still marked as incubating. For this reason many may be reluctant to use it. I tend to assume that incubating means not ready for production use. I do have a task to move to the new publication method, but it hasn’t happened yet.
The server does indeed return a 401. However some http client implementations will not then automatically authenticate if the 'content; is being streamed. This is where they can’t reset the stream to the beginning and repeat it. The venerable java.net.HttpURLConnection certainly does this (and documents it https://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#setFixedLengthStreamingMode(int))
It is production ready. Incubating simply means the API may change in the future.
https://docs.gradle.org/current/userguide/feature_lifecycle.html
We have no control of the HTTP client implementation being used by the Maven Wagon used by the ‘maven’ plugin so unless there are some system properties that control this behavior your only option is to switch to the ‘maven-publish’ plugin.
Unfortunately switching to maven-publish is far from trivial. Is there still no sensible way to integration test a plugin?
I’m not sure if this question is related to this topic at all but have you looked at the Gradle TestKit?
I will look at Gradle TestKit. However I was also intending to switch the repository to webdav, but I see that is not supported with maven-publish. So it seems I have no where to go with this problem 
Switching to webdav could potentially fix the problem since it would use a different wagon implementation. It’s worth a try.