Publishing to webdav is not yet supported by the new publishing plugins. Unfortunately this means you’re stuck with the old publishing mechanism for now.
We are looking to so something similar here by publishing to S3 (using the maven-s3-wagon). Is there a thought on how this should be implemented? Something similar to the how it’s implemented in the original ‘maven’ plugin?
I think the basic goal is to add some libraries to the classpath of the ant task that is backing the PublishToMavenRepository tasks, correct?
@john, I would say there are two part to the solution:
The first part is some DSL for defining S3 as a target repository, so you can do something like:
publishing {
repositories {
s3 { … }
}
}
The second part is an implementation to wire up the maven publishing plugin to S3. There are a couple of options here:
Bundle the appropriate wagon jar in the Gradle distribution, and map the S3 configuration to the appropriate Maven Repository configuration. We’d also need to fail gracefully when you tried to publish an Ivy module to S3, or to resolve things from S3.
Add a Gradle S3 repository implementation (a RepositoryTransport implementation) and an adapter from the Wagon -> Gradle APIs. This would allow S3 to be used for any kind of publication and also for resolving.
These aren’t mutually exclusive. We could do the first and later move to the second.
I should also add that the second option above would also mean that the maven-publish plugin would then be able to publish to any kind of repository that Gradle understands (eg sftp), as the ivy-publish plugin can.
@adam - would a new DSL really be necessary for utilizing S3 repos? It’s not a new repo type, it’s just a different protocol for talking to the repo. I was envisioning something more like:
publishing {
repositories {
maven {
url ‘s3://my-bucket/’
}
}
}
In this way, everything would still be stored in either a Maven or Ivy layout, just on an S3 backend.
For maven-publish this works as long as I can get the wagon jar into the PlexusContainer (using addJarResource(File…), which is what the old maven plugin does)
I like the idea of just adding a RepositoryTransport implementation, but would it be useful to create a more open API that allowed a user to add their own implementations (then build authors or plugins could add support for various protocols without changes to core)?
Last thing - I am initially using this S3-Wagon plugin: https://github.com/jcaddel/maven-s3-wagon, but it lacks a good API for providing the S3 credentials. It currently only supports through ENV vars, System properties, ~/.m2/settings.xml, or IAM through support in the AWS Java SDK.
In order to adhere to the Gradle Repository API, it will need to support using the configured PasswordCredentials. Would it be better to reimplement this code in Gradle natively instead of relying on a 3rd party library?
@john, good point. It should just be another protocol.
One question is what to do about credentials in the repositories { } definition - S3 doesn’t actually use username + password authentication, I don’t think. It would be nice to have some S3 specific credentials DSL that a build author can use in the repository definition. We also want something similar for the sftp protocol.
Re. adding the RepositoryTransport implementation - the idea is definitely to add some public API for this at some point. I’d probably add the S3 protocol and then extract the API later, but we could do things in the other way around.
Re. handling the credentials,if the 3rd party lib works out (and runs on Java 6) then we should go with that. If it’s awkward, then we should just implement it in Gradle.
Re: credentials - are you thinking just a new block under the repository definition:
repositories {
maven {
url ‘s3://mybucket’
s3credentials {
accessKey = ‘myaccesskey’
secretKey = ‘mysecret’
}
}
}
Or some variation like that? Or possible just additional properties under the existing ‘credentials’ DSL? I like something like this, but it doesn’t lend itself to validating that the proper items are configured.
I think the best way is to handle this through documentation (document that ways that credentials for S3 can be provided including setting the username/password to be the accessKey/secretKey).
For sftp, are you thinking supporting Public/Private Key auth?
We’ve recently added resolution from an AWS S3 repository, and there’s an outstanding pull request to add S3 publishing support, with a Maven Wagon -> Gradle Repository bridge.