Gilles, IMO, you are going towards client-server model as you want more and more repository capabilities (like advanced search).
Personally, I see a lot of advantages if a repository would be kind of server (say HTTP server with searching capabilities) and the client would ask it to search in a standard way (e.g. search URL or maybe better: web-service with WSDL). In client-only approach (as today) we have possible problems like a single repository that may be used by several clients, probably with different ivy versions or transactions issues where 2 clients publish / resolve at the same time. So client-server approach with well defined interface (e.g. WSDL) is a good idea but something is missing: we don't use files any more but URLs. Personally, I prefer using file-system repositories for internal organization use for their speed and ease of management. The 'useOrigin' feature of Ivy 1.4 also helps. Ideally, if I wasn't see Maven in the past, I would not have been thinking about cache at all. Instead, I would have just creating a tool to build a classpath above file-system 'repositories' that creates paths, and the cache would not have been needed at all. Why I am telling you all of this story? What I am trying to say is that we have inherent conflict in the concepts: 'smart' client-server approach vs. 'simple/dumb' file-system structure with the login in clients. The problem with file-system approach is that the logic is in the client, as I wrote above. A possible solution (not trivial at all) is to combine the approaches: write client-server system where the 'server' is not HTTP server but SMB (Samba) based server. SMB exposes file-system interface but may (I am not sure. Need to check this) implement internal logic like transactions, locking, search (using dummy paths/files like the proc in Linux) and so on, as you can do with an HTTP server and servlets. I just wanted to take your question about the search capability a step further and imagine the possible problems we will get, and the inherent approaches conflict. Do you agree? easyproglife. On 11/15/06, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> -----Original Message----- > From: Xavier Hanin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 15, 2006 4:33 PM > To: [email protected] > Subject: Re: Dependency standards > > On 11/15/06, Gilles Scokart <[EMAIL PROTECTED]> wrote: > > > > > > > > It would be a good thing to add the focus on java project into the > > description of ivy (http://incubator.apache.org/projects/ivy.html). > > > Well, I don't know how important it is. Ivy has been designed > to address dependency management, but is more focused on Java > dependency management, because it's a java tool and because > of its defaults values (jar for artifacts types for > instance). But it isn't only java focused. > > On the other hand, I don't think it can compete with tools > like ruby gems or perl CPAN, because they are tools dedicated > to other languages, and will always be better for those > languages needs. > > I don't say I don't want to say that Ivy is java focused, I > don't mind, I don't think I'll ever use it for something > else. But if a user community appear who want to use it to > deal with another language dependency management, and if they > submit patches to better support it, I think this could be > easily accepted as soon as it doesn't alter the core philosophy. > > Xavier > Thanks for the clarification. By the way, there is an other point to clarify concerning the scope of ivy. It is how far ivy goes (or want to go) in term of repository management. There is already some important steps that ivy cover : how to access a repository and how to fill a repository, how to search artefact in a repository (limited to searching for last integration, last release, etc), replicating/transforming repositories... Etc. What is the intention there? Where will ivy stop? (expl: more advanced search, cleaning repositories)
