incubator-depot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: Moving forward or letting go
Date Thu, 17 Jun 2004 21:35:28 GMT

> > 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


Mime
View raw message