Looks good to me. I’ve added a few more things - we should reuse the transports and caching for remote build scripts, and add some basic credentials management as well (eg prompting at the command-line, tooling API integration)
On 24 Feb 2014, at 1:46 pm, Daz DeBoer <darrell.deb...@gradleware.com> wrote: > I've pushed an initial cut of the spec: feel free to modify as you discover > things that don't make sense. > https://github.com/gradle/gradle/blob/master/design-docs/repository-transports.md > > > > On Sun, Feb 23, 2014 at 4:10 PM, Marcin Erdmann <marcin.erdm...@proxerd.pl> > wrote: > Sounds like a plan. > > > On Sun, Feb 23, 2014 at 11:02 PM, Adam Murdoch <adam.murd...@gradleware.com> > wrote: > > On 24 Feb 2014, at 9:36 am, Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote: > >> >> >> >> On Sun, Feb 23, 2014 at 10:33 PM, Daz DeBoer <darrell.deb...@gradleware.com> >> wrote: >> >> 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. >> >> Would be great if you could draft it. You probably have a much better idea >> about the requirements than I do. > > > If you’re keen to get started while we’re getting the spec together, you > might do a quick spike with one or both of the clients to see what’s required > to get them to talk to an ssh server, and if you have a preference between > sshd or jsch. You could even start with an integration test that uses the > sshd test fixture and drives the client(s) directly. We could then refactor > this into the real implementation. > > The sorts of things we’ll need to be able to do: > > - Read the meta-data for a file, including whether it exists or not, plus the > size and last modified time of the file. > - Read from a file. > - Write to a file. > - Create file. > - List the entries of a directory. > > When things fail, it would be really nice to be able tell the difference > between a failure where the thing did not exist, vs a failure where there is > some permission problem, vs the server is not running, vs everything else. > > I suspect error handling will be the deciding factor between the two clients. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > > > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
