On 24 Feb 2014, at 9:12 am, 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. > > 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. I’d slightly prefer we use apache sshd rather than jsch, but it’s not a strong opinion. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
