On Thu, Feb 20, 2014 at 8:33 PM, Adam Murdoch <adam.murd...@gradleware.com>wrote:
> > On 19 Feb 2014, at 3:06 pm, Daz DeBoer <darrell.deb...@gradleware.com> > wrote: > > Hey Marcin > That's great. If you want to take a stab at a design spec for supporting > an sftp repository transport, that would be a good start. This can go into > a new document: /design-docs/repository-transports.md. > > For the first story I think it should be sufficient to simply support a ' > sftp://host[:port]' type URL, together with the existing user/password > credentials. But we should probably start thinking about how we can support > other authentication mechanisms as well (for all transports) > > > That would be good. I would love to make credentials a first-class concept > and expose some nice command-line and tooling API mechanisms to provide and > manage them. > > > We also need to start thinking about how we're going to provide adequate > test coverage for different repository transports. Do we want to run all of > our remote resolution tests against all remote transports, or choose a > subset of tests that would be sufficient for demonstrating a particular > transport behaves correctly? We can probably come up with > a org.gradle.integtests.fixtures.AbstractMultiTestRunner subclass that can > run a set of tests against a defined set of transports. > > > One thing that the current test coverage does is to verify exactly which > network requests are being made when. This is really important from a > performance point of view. I would not want to lose this coverage if we > were to abstract some of the tests away from transport, and any new > transports should have a similar kind of coverage. Perhaps we might change > the test fixtures to abstract some of the verifications (there's really > only a handful of different interactions we need to check for). > Seems like a valid point. Looks like you're talking about specs that are using org.gradle.test.fixtures.maven.HttpResource.expect...() methods. We could abstract that to something like RemoteResource and use that to run all these tests agains all transports. I didn't get much time to have a look at this stuff this weekend because I spent it contributing to Ratpack but I seem to have found test code that exercises transports so I should be able to get started this week. I will look at this code more and start drafting the design spec. Do you guys have a preferred library to use as the sftp client? Should we use SSHD (https://mina.apache.org/sshd-project/index.html) or JSch( http://www.jcraft.com/jsch/)? SSHD seems to also provide a sftp server implementation which would be useful for fixtures.
