> > Also, I think this problem can only be broken with small/focused/standalone > > tools -- like a browser separate from an HTTP server -- so folks don't get > > into an all or nothing situation. Hence, I think Depot ought start as a > > client, maybe forever. > Well, it was always my main intent to have a small tool to help solve > the dependency issues during the build process. Also, as far as I am > concerned I would like to see Depot evolving into the Ant area. > Ant is still somewhat of a standard in the build community and it was > never really a topic to also solve other dependencies as build > dependencies (means, we are not resolving runtime dependencies, right?).
Yup, we need to keep it small and simple/focsed. Nothing fancy. Nick's done some good work with Ant, and we have some tasks and types. Maybe we need to just try to get those out, for now. > > So -- Avalon repository. How do we see about talking to it? What > > protocols/APIs? Depot tends to use HTTP (to a file system based repository, > > ala Maven's Ibiblio, ala ASFRepo spec.) What more is wanted? > Sure, there are lots of other protocols which could be supported, but > the one working is HTTP, and to solve lots of the dependency issues in > Depot I believe we should restrict the usage to HTTP. If Depot evolves, > we still could add more, but ... That is my view (hence we depend upon java.net with optional dependencies on HttpClient and VFS) with VFS being the protocol extension point (not our ballywack). I think of one as simple (in a non-derogatory way) jsut a file system w/ HTTP access, but maybe Avalon's is different. Here I was trying to find out more about Avalon's repository. regards Adam
