On Sun, Feb 23, 2014 at 3:12 PM, Marcin Erdmann <marcin.erdm...@proxerd.pl>wrote:
> > > > 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. > Yes. It seems like we could extract an API out of org.gradle.test.fixtures.server.http.HttpServer which would be implemented by org.gradle.test.fixtures.server.sftp.SFTPServer as well. Then the fixtures in org.gradle.test.fixtures.ivy and org.gradle.test.fixtures.maven could be adapted to deal in terms of this 'server expectation' API. This would allow us to run any tests that us these fixtures against both server implementations. > > 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. > Excellent. I was planning on putting a first draft of the design spec up today; likely pretty basic to start with. > > 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. > I don't really have experience with either of these, but it looks like we're currently using both in our test fixture code (org.gradle.test.fixtures.server.sftp.SFTPServer) as well as providing jcraft for Ivy to use in it's SFtpResolver. Thanks Daz
