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). -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
