You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Gilles Scokart <gs...@gmail.com> on 2006/11/15 16:00:11 UTC
Ivy scope clarification
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Wednesday, November 15, 2006 4:33 PM
> To: ivy-dev@incubator.apache.org
> Subject: Re: Dependency standards
>
> On 11/15/06, Gilles Scokart <gs...@gmail.com> 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)
Re: Ivy scope clarification
Posted by Stephen Nesbitt <sn...@cobaltgroup.com>.
On Wednesday 15 November 2006 8:54 am, Xavier Hanin wrote:
> On 11/15/06, Gilles Scokart <gs...@gmail.com> wrote:
> > <snip>
> > 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)
>
> I don't know. I have already seen users asking for more repository
> management features, as those you evoke. So in my mind if there is a
> strong user need, then we should try to address it, otherwise it will
> be done in another tool, and we will have to keep tools in sync.
>
> But maybe others think that repository management should not be so
> tightly coupled with dependency management?
My initial reaction would be that repository management should not be
tightly coupled with dependency management. Nor do I think repository
management should be a development priority at this time.
I am dependent on Ivy for dependency management. I am not dependent on Ivy
for repository management.
-steve
--
Stephen Nesbitt
CM Architect/Lead
The Cobalt Group
snesbitt@cobaltgroup.com
x8271
Re: Ivy scope clarification
Posted by Xavier Hanin <xa...@gmail.com>.
On 11/15/06, Gilles Scokart <gs...@gmail.com> wrote:
>
> <snip>
> 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)
I don't know. I have already seen users asking for more repository
management features, as those you evoke. So in my mind if there is a strong
user need, then we should try to address it, otherwise it will be done in
another tool, and we will have to keep tools in sync.
But maybe others think that repository management should not be so tightly
coupled with dependency management?
Xavier
Re: Ivy scope clarification
Posted by easyproglife <ea...@gmail.com>.
On 11/15/06, Steve Loughran <st...@apache.org> wrote:
>
>
> >
> > 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.
>
> 1. I've never seen a well defined WSDL interface.
> 2. You only get TX with WS-ReliableMessaging and WS-TX, and nobody does
> those.
Forget about the SOAP and WSDL. They were just an example. Maybe a wrong
one.
Well-defined URLs are fine to me. (Well defined means you know exactly what
is the search URL, what parameters it takes and what response it gives.)
>
> > 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.
>
> Its a bit like the original visual source safe tool and early databases,
> where everything was on a shared FS. It doesnt scale to many clients or
> long haul connectivy. But HTTP does because Proxies can cache GET calls,
> and because most clients do not try and make the remote server look like
> something it isnt: a local filesystem.
HTTP and URLs are fine. Just remember the price: handling client-cache. You
need client-side logic to invalidate and refresh the cache. Still not ideal
client-server design. (because you probably can never do ideal client-server
design where you use raw file system files; the cache in this case.)
>
> > 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.
>
> SMB is mediocre for long haul connectivity, doesnt have a search API
> (AFAIK) or offer a transacted API. Vista FS has TX support; I dont know
> if this is exposed over SMB.
>
> If you want a repository with write access,
>
> 0. Stick with URLs. You get caching from proxies, easy browsing and the
> ability to fetch from anything with <get>
> 1. use WebDAV.
> 2. use a PUT operation to put something new up
> 3. use GET to retrieve
> 4. use DELETE to delete
> 5. use HEAD to poll for changes, or GET with etag header
> 6. provide an atom feed of changes that a client can poll to invalidate
> the local cache.
See my comment above about cache invalidate (= client side logic, =
incompatibility between versions, = race conditions unless every developer
has it's own cache that wastes disk space and build time).
easyproglife.
-Steve
>
>
Re: Ivy scope clarification
Posted by Xavier Hanin <xa...@gmail.com>.
On 11/16/06, Brett Porter <br...@apache.org> wrote:
>
>
> On 16/11/2006, at 4:03 AM, Xavier Hanin wrote:
>
> > BTW, do you guys have heard of archiva http://maven.apache.org/
> > archiva/ ?
> > There are a lot of good ideas there, even if it's just too maven
> > focused to
> > be really useful for us directly.
>
> I'd say POM-centric more than Maven centric. It should be useful to
> Ivy to the extent that Ivy can interoperate with any Maven repository.
You're right. The probem is that pom compatibility is still not working
perfectly, but once we'll have worked on that, we could leverage archiva too
as a nice side effect :)
- Brett
>
Re: Ivy scope clarification
Posted by Brett Porter <br...@apache.org>.
On 16/11/2006, at 4:03 AM, Xavier Hanin wrote:
> BTW, do you guys have heard of archiva http://maven.apache.org/
> archiva/ ?
> There are a lot of good ideas there, even if it's just too maven
> focused to
> be really useful for us directly.
I'd say POM-centric more than Maven centric. It should be useful to
Ivy to the extent that Ivy can interoperate with any Maven repository.
- Brett
Re: Ivy scope clarification
Posted by Xavier Hanin <xa...@gmail.com>.
On 11/15/06, easyproglife <ea...@gmail.com> wrote:
>
> OK.
>
> First use case: every developer has its own private cache.
> Can work well but everyone has to download (at least once) all the
> artifacts
> he needs.
> In addition, it duplicates artifacts and waste disk space. Usually people
> say: space is not an issue today. Maybe. :-/
>
> Second use case: a group of people share a cache.
> The truth is that I don't remember if you suggested in the past not to
> share
> the cache. If so - use the first use case and ignore the rest of the
> email.
>
> Otherwise, if the cache could be shared, let's imagine the "race
> condition":
>
> (Race condition means two or more people are trying to do some tasks on
> the
> same resources, and the results depends on the exact (random) order they
> did
> it. For example: writing to the same unlocked file. The results are
> according to the last writer of course. See also:
> http://en.wikipedia.org/wiki/Race_condition )
>
> Think would would happen if two people updates the cache in parallel. Many
> situations could be here. For example: one person downloading an artifact.
> ivy.xml has been downloaded. The jar - not yet. The another people is
> trying
> to use this artifacts. What he see? an ivy.xml without the jar. What will
> the second people's ivy do? Will also try downloading the same jar?
>
> This is just an example. There are probably many other examples.
>
> The idea is simple: when two people share the same resource without a
> locking mechanism, you cannot guarantee data integrity (that's why DB came
> to the world).
>
> I was talking about the second use case on my previous mail.
>
> The first use case (one person = one cache) is fine but wasting time and
> disk space.
>
>
> Have I explained my previous mail?
Yes, thanks for your light, I was thinking only at the first use case,
that's why I had trouble to understand. Using a shared cache is not
currently supported by Ivy, some time I thought it shouldn't be too
difficult to support it, but now that I've read you e-mail I won't suggest
it :-) So I think we'll have to stay with the one person = one cache for
the moment. What can be done is improve the wasting time part of the problem
of using individual caches, by providing some kind of proxy repository, as
maven does.
Note that we could choose to avoid a cache altogether (as with
useOrigin=true) even for url repository, if the tools needing artifacts
support URL for artifacts. My experience has not shown a strong need to
avoid a cache so far, so I won't push for this kind of things. But I know
that some have thought about using Ivy on a cellphone, and I can understand
that disk space may be an issue in such environment.
Xavier
easyproglife.
>
> On 11/15/06, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > On 11/15/06, easyproglife <ea...@gmail.com> wrote:
> > >
> > > Xavier,
> > >
> > > As I wrote to Steve, the HTTP ideas are great! Servlet is also a great
> > > idea
> > > comparing to current parsing of Apache web server list response.
> > >
> > > But the price!
> > >
> > > The price is in the cache. You still would have to manage the cache
> with
> > > client-side logic, different ivy versions and race conditions.
> >
> >
> > I'm sorry but I do not see what you mean. I don't even know what race
> > conditions means :) Forgive my ignorance, could you please give more
> > details
> > on what you mean.
> >
> > Xavier
> >
> > Isn't this an inherent issue while trying to combine dumb file system
> > (with
> > > client logic) and web server (with internal logic)?
> > >
> > > easyproglife.
> > >
> > > On 11/15/06, Xavier Hanin <xa...@gmail.com> wrote:
> > > >
> > > > On 11/15/06, Steve Loughran <st...@apache.org> wrote:
> > > > >
> > > > > If you want a repository with write access,
> > > > >
> > > > > 0. Stick with URLs. You get caching from proxies, easy browsing
> and
> > > the
> > > > > ability to fetch from anything with <get>
> > > > > 1. use WebDAV.
> > > > > 2. use a PUT operation to put something new up
> > > > > 3. use GET to retrieve
> > > > > 4. use DELETE to delete
> > > > > 5. use HEAD to poll for changes, or GET with etag header
> > > > > 6. provide an atom feed of changes that a client can poll to
> > > invalidate
> > > > > the local cache.
> > > >
> > > >
> > > > This is a very clean approach, I would only add something for
> > searching
> > > > (I'm
> > > > not familiar with GET with etag header, but it should fit the search
> > > need
> > > > too).
> > > >
> > > > BTW, do you guys have heard of archiva
> > http://maven.apache.org/archiva/?
> > > > There are a lot of good ideas there, even if it's just too maven
> > focused
> > > > to
> > > > be really useful for us directly.
> > > >
> > > > Another point, FYI, we have developed at jayasoft a very simple
> > > > Servlet/DependencyResolver pair, to avoid using apache directory
> > listing
> > > > (which is very slow) to find the last version of a module, but
> instead
> > > ask
> > > > the servlet (with a simple GET) which one it is. It's a very basic
> > > > implementation of part of what you're suggesting, and I think I
> could
> > > > easily
> > > > share its code with you if some are interested (but it was the very
> > > > servlet
> > > > development done by the person who did it, two years ago, so the
> code
> > is
> > > > not
> > > > very clean, but it works and can be a basis for this kind of
> > > development.
> > > >
> > > > Xavier
> > > >
> > > > -Steve
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Ivy scope clarification
Posted by easyproglife <ea...@gmail.com>.
OK.
First use case: every developer has its own private cache.
Can work well but everyone has to download (at least once) all the artifacts
he needs.
In addition, it duplicates artifacts and waste disk space. Usually people
say: space is not an issue today. Maybe. :-/
Second use case: a group of people share a cache.
The truth is that I don't remember if you suggested in the past not to share
the cache. If so - use the first use case and ignore the rest of the email.
Otherwise, if the cache could be shared, let's imagine the "race condition":
(Race condition means two or more people are trying to do some tasks on the
same resources, and the results depends on the exact (random) order they did
it. For example: writing to the same unlocked file. The results are
according to the last writer of course. See also:
http://en.wikipedia.org/wiki/Race_condition )
Think would would happen if two people updates the cache in parallel. Many
situations could be here. For example: one person downloading an artifact.
ivy.xml has been downloaded. The jar - not yet. The another people is trying
to use this artifacts. What he see? an ivy.xml without the jar. What will
the second people's ivy do? Will also try downloading the same jar?
This is just an example. There are probably many other examples.
The idea is simple: when two people share the same resource without a
locking mechanism, you cannot guarantee data integrity (that's why DB came
to the world).
I was talking about the second use case on my previous mail.
The first use case (one person = one cache) is fine but wasting time and
disk space.
Have I explained my previous mail?
easyproglife.
On 11/15/06, Xavier Hanin <xa...@gmail.com> wrote:
>
> On 11/15/06, easyproglife <ea...@gmail.com> wrote:
> >
> > Xavier,
> >
> > As I wrote to Steve, the HTTP ideas are great! Servlet is also a great
> > idea
> > comparing to current parsing of Apache web server list response.
> >
> > But the price!
> >
> > The price is in the cache. You still would have to manage the cache with
> > client-side logic, different ivy versions and race conditions.
>
>
> I'm sorry but I do not see what you mean. I don't even know what race
> conditions means :) Forgive my ignorance, could you please give more
> details
> on what you mean.
>
> Xavier
>
> Isn't this an inherent issue while trying to combine dumb file system
> (with
> > client logic) and web server (with internal logic)?
> >
> > easyproglife.
> >
> > On 11/15/06, Xavier Hanin <xa...@gmail.com> wrote:
> > >
> > > On 11/15/06, Steve Loughran <st...@apache.org> wrote:
> > > >
> > > > If you want a repository with write access,
> > > >
> > > > 0. Stick with URLs. You get caching from proxies, easy browsing and
> > the
> > > > ability to fetch from anything with <get>
> > > > 1. use WebDAV.
> > > > 2. use a PUT operation to put something new up
> > > > 3. use GET to retrieve
> > > > 4. use DELETE to delete
> > > > 5. use HEAD to poll for changes, or GET with etag header
> > > > 6. provide an atom feed of changes that a client can poll to
> > invalidate
> > > > the local cache.
> > >
> > >
> > > This is a very clean approach, I would only add something for
> searching
> > > (I'm
> > > not familiar with GET with etag header, but it should fit the search
> > need
> > > too).
> > >
> > > BTW, do you guys have heard of archiva
> http://maven.apache.org/archiva/?
> > > There are a lot of good ideas there, even if it's just too maven
> focused
> > > to
> > > be really useful for us directly.
> > >
> > > Another point, FYI, we have developed at jayasoft a very simple
> > > Servlet/DependencyResolver pair, to avoid using apache directory
> listing
> > > (which is very slow) to find the last version of a module, but instead
> > ask
> > > the servlet (with a simple GET) which one it is. It's a very basic
> > > implementation of part of what you're suggesting, and I think I could
> > > easily
> > > share its code with you if some are interested (but it was the very
> > > servlet
> > > development done by the person who did it, two years ago, so the code
> is
> > > not
> > > very clean, but it works and can be a basis for this kind of
> > development.
> > >
> > > Xavier
> > >
> > > -Steve
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: Ivy scope clarification
Posted by Xavier Hanin <xa...@gmail.com>.
On 11/15/06, easyproglife <ea...@gmail.com> wrote:
>
> Xavier,
>
> As I wrote to Steve, the HTTP ideas are great! Servlet is also a great
> idea
> comparing to current parsing of Apache web server list response.
>
> But the price!
>
> The price is in the cache. You still would have to manage the cache with
> client-side logic, different ivy versions and race conditions.
I'm sorry but I do not see what you mean. I don't even know what race
conditions means :) Forgive my ignorance, could you please give more details
on what you mean.
Xavier
Isn't this an inherent issue while trying to combine dumb file system (with
> client logic) and web server (with internal logic)?
>
> easyproglife.
>
> On 11/15/06, Xavier Hanin <xa...@gmail.com> wrote:
> >
> > On 11/15/06, Steve Loughran <st...@apache.org> wrote:
> > >
> > > If you want a repository with write access,
> > >
> > > 0. Stick with URLs. You get caching from proxies, easy browsing and
> the
> > > ability to fetch from anything with <get>
> > > 1. use WebDAV.
> > > 2. use a PUT operation to put something new up
> > > 3. use GET to retrieve
> > > 4. use DELETE to delete
> > > 5. use HEAD to poll for changes, or GET with etag header
> > > 6. provide an atom feed of changes that a client can poll to
> invalidate
> > > the local cache.
> >
> >
> > This is a very clean approach, I would only add something for searching
> > (I'm
> > not familiar with GET with etag header, but it should fit the search
> need
> > too).
> >
> > BTW, do you guys have heard of archiva http://maven.apache.org/archiva/?
> > There are a lot of good ideas there, even if it's just too maven focused
> > to
> > be really useful for us directly.
> >
> > Another point, FYI, we have developed at jayasoft a very simple
> > Servlet/DependencyResolver pair, to avoid using apache directory listing
> > (which is very slow) to find the last version of a module, but instead
> ask
> > the servlet (with a simple GET) which one it is. It's a very basic
> > implementation of part of what you're suggesting, and I think I could
> > easily
> > share its code with you if some are interested (but it was the very
> > servlet
> > development done by the person who did it, two years ago, so the code is
> > not
> > very clean, but it works and can be a basis for this kind of
> development.
> >
> > Xavier
> >
> > -Steve
> > >
> > >
> >
> >
>
>
Re: Ivy scope clarification
Posted by easyproglife <ea...@gmail.com>.
Xavier,
As I wrote to Steve, the HTTP ideas are great! Servlet is also a great idea
comparing to current parsing of Apache web server list response.
But the price!
The price is in the cache. You still would have to manage the cache with
client-side logic, different ivy versions and race conditions.
Isn't this an inherent issue while trying to combine dumb file system (with
client logic) and web server (with internal logic)?
easyproglife.
On 11/15/06, Xavier Hanin <xa...@gmail.com> wrote:
>
> On 11/15/06, Steve Loughran <st...@apache.org> wrote:
> >
> > If you want a repository with write access,
> >
> > 0. Stick with URLs. You get caching from proxies, easy browsing and the
> > ability to fetch from anything with <get>
> > 1. use WebDAV.
> > 2. use a PUT operation to put something new up
> > 3. use GET to retrieve
> > 4. use DELETE to delete
> > 5. use HEAD to poll for changes, or GET with etag header
> > 6. provide an atom feed of changes that a client can poll to invalidate
> > the local cache.
>
>
> This is a very clean approach, I would only add something for searching
> (I'm
> not familiar with GET with etag header, but it should fit the search need
> too).
>
> BTW, do you guys have heard of archiva http://maven.apache.org/archiva/ ?
> There are a lot of good ideas there, even if it's just too maven focused
> to
> be really useful for us directly.
>
> Another point, FYI, we have developed at jayasoft a very simple
> Servlet/DependencyResolver pair, to avoid using apache directory listing
> (which is very slow) to find the last version of a module, but instead ask
> the servlet (with a simple GET) which one it is. It's a very basic
> implementation of part of what you're suggesting, and I think I could
> easily
> share its code with you if some are interested (but it was the very
> servlet
> development done by the person who did it, two years ago, so the code is
> not
> very clean, but it works and can be a basis for this kind of development.
>
> Xavier
>
> -Steve
> >
> >
>
>
Re: Ivy scope clarification
Posted by Xavier Hanin <xa...@gmail.com>.
On 11/15/06, Steve Loughran <st...@apache.org> wrote:
>
> If you want a repository with write access,
>
> 0. Stick with URLs. You get caching from proxies, easy browsing and the
> ability to fetch from anything with <get>
> 1. use WebDAV.
> 2. use a PUT operation to put something new up
> 3. use GET to retrieve
> 4. use DELETE to delete
> 5. use HEAD to poll for changes, or GET with etag header
> 6. provide an atom feed of changes that a client can poll to invalidate
> the local cache.
This is a very clean approach, I would only add something for searching (I'm
not familiar with GET with etag header, but it should fit the search need
too).
BTW, do you guys have heard of archiva http://maven.apache.org/archiva/ ?
There are a lot of good ideas there, even if it's just too maven focused to
be really useful for us directly.
Another point, FYI, we have developed at jayasoft a very simple
Servlet/DependencyResolver pair, to avoid using apache directory listing
(which is very slow) to find the last version of a module, but instead ask
the servlet (with a simple GET) which one it is. It's a very basic
implementation of part of what you're suggesting, and I think I could easily
share its code with you if some are interested (but it was the very servlet
development done by the person who did it, two years ago, so the code is not
very clean, but it works and can be a basis for this kind of development.
Xavier
-Steve
>
>
Re: Ivy scope clarification
Posted by Steve Loughran <st...@apache.org>.
easyproglife wrote:
> 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 )
0. Something for somebody to handle, which is what mvnrepo does for me
>or maybe better: web-service with WSDL).
-1. No SOAP, no WSDL. I speak as the author of one and a bit SOAP stacks.
>
> 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.
I wondered about race conditions.
>
> 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.
1. I've never seen a well defined WSDL interface.
2. You only get TX with WS-ReliableMessaging and WS-TX, and nobody does
those.
>
> 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.
Its a bit like the original visual source safe tool and early databases,
where everything was on a shared FS. It doesnt scale to many clients or
long haul connectivy. But HTTP does because Proxies can cache GET calls,
and because most clients do not try and make the remote server look like
something it isnt: a local filesystem.
>
> 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.
SMB is mediocre for long haul connectivity, doesnt have a search API
(AFAIK) or offer a transacted API. Vista FS has TX support; I dont know
if this is exposed over SMB.
If you want a repository with write access,
0. Stick with URLs. You get caching from proxies, easy browsing and the
ability to fetch from anything with <get>
1. use WebDAV.
2. use a PUT operation to put something new up
3. use GET to retrieve
4. use DELETE to delete
5. use HEAD to poll for changes, or GET with etag header
6. provide an atom feed of changes that a client can poll to invalidate
the local cache.
-Steve
Re: Ivy scope clarification
Posted by easyproglife <ea...@gmail.com>.
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 <gs...@gmail.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Wednesday, November 15, 2006 4:33 PM
> > To: ivy-dev@incubator.apache.org
> > Subject: Re: Dependency standards
> >
> > On 11/15/06, Gilles Scokart <gs...@gmail.com> 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)
>
>
>