You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by "Brown, Carlton" <Ca...@compucredit.com> on 2008/03/14 14:45:48 UTC
Does Ivy really have a cache resolver?
I notice in IVY-612 there is a tantalizing hint at the existence of an
undocumented resolver type called a "cache resolver". Is this a
resolver that queries only the cache? Please tell me this is true, it
would really be useful for me.
I will be happy to generate a documentation patch for IVY-612 if someone
will explain how the cache resolver works.
https://issues.apache.org/jira/browse/IVY-612
Here again is an example of how Ivy always seems to have an answer for
every question I can imagine. It's very refreshing to see a tool cover
a particular problem domain with such completeness and correctness,
anticipating the user's every need instead of dictating a certain
convention.
Thanks,
Carlton
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
Re: Does Ivy really have a cache resolver?
Posted by Xavier Hanin <xa...@gmail.com>.
On Tue, Mar 18, 2008 at 2:40 PM, Brown, Carlton <
Carlton.Brown@compucredit.com> wrote:
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Monday, March 17, 2008 1:22 PM
> > To: ivy-user@ant.apache.org
> > Subject: Re: Does Ivy really have a cache resolver?
> >
> > CacheResolver has been introduced quite a long time ago and
> > never documented because it wasn't supposed to be public. I'm
> > still not sure it's a good idea to use it... IMO, Ivy caching
> > mechanism should be strong enough to avoid the requirement
> > for a cache resolver, at least at resolve time. With the
> > addition of dynamic revisions caching in beta 2, now Ivy
> > cache has all information necessary to be able to perform a
> > resolve from the cache, without actually requiring to use the
> > cache resolver. This may require some improvement, like
> > accepting to use dynamic revision resolution cached data even
> > when they have exceeded their TTL. This could be a special
> > resolve mode or refresh mode. With this improvement, the last
> > thing for which the cache resolver would still be useful is
> > publishing. But even in this case, I'd prefer using a local
> > repository with useOrigin="true": the behavior is sligthly
> > different, but I think this should address all the needs
> > covered by cache resolver which only has its root in bad
> > caching support and is a design flaw. What do you think? Do
> > you see a use case where CacheResolver is really necessary?
>
> Like you said, publishing is the situation where a CacheResolver is
> really needed. It's true we can work around this by implementing a
> local repository as our cache. But that duplicates artifact storage,
> wastes disk space, etc.
With useOrigin=true there's no duplication at all.
Also we'd need to duplicate some sort of
> cleaning strategy that already exists with <ivy:clean>
Good point. But I find this cleaner to isolate cache (which you can always
safely clean, since it should never have data that isn't available somewhere
else) from repositories (which stores the actual data). In the case of an
artifact you want only to share between two projects on the same box, one
good answer may be to use directly the artifact where your project builds
it, instead of having to publish it at all.
>
>
> Considering that Ivy already has a perfectly good cache, it seems
> inefficient and wasteful to duplicate that functionality. But I concede
> that the local repo workaround is not too much of a hardship, and there
> are more important issues to be worked right now.
Agreed.
Xavier
>
>
> -----------------------------------------
> ====================================================
> This message contains PRIVILEGED and CONFIDENTIAL
> information that is intended only for use by the
> named recipient. If you are not the named recipient,
> any disclosure, dissemination, or action based on
> the contents of this message is prohibited. In such
> case please notify us and destroy and delete all
> copies of this transmission. Thank you.
> ====================================================
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: Does Ivy really have a cache resolver?
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
> -----Original Message-----
> From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> Sent: Monday, March 17, 2008 1:22 PM
> To: ivy-user@ant.apache.org
> Subject: Re: Does Ivy really have a cache resolver?
>
> CacheResolver has been introduced quite a long time ago and
> never documented because it wasn't supposed to be public. I'm
> still not sure it's a good idea to use it... IMO, Ivy caching
> mechanism should be strong enough to avoid the requirement
> for a cache resolver, at least at resolve time. With the
> addition of dynamic revisions caching in beta 2, now Ivy
> cache has all information necessary to be able to perform a
> resolve from the cache, without actually requiring to use the
> cache resolver. This may require some improvement, like
> accepting to use dynamic revision resolution cached data even
> when they have exceeded their TTL. This could be a special
> resolve mode or refresh mode. With this improvement, the last
> thing for which the cache resolver would still be useful is
> publishing. But even in this case, I'd prefer using a local
> repository with useOrigin="true": the behavior is sligthly
> different, but I think this should address all the needs
> covered by cache resolver which only has its root in bad
> caching support and is a design flaw. What do you think? Do
> you see a use case where CacheResolver is really necessary?
Like you said, publishing is the situation where a CacheResolver is
really needed. It's true we can work around this by implementing a
local repository as our cache. But that duplicates artifact storage,
wastes disk space, etc. Also we'd need to duplicate some sort of
cleaning strategy that already exists with <ivy:clean>
Considering that Ivy already has a perfectly good cache, it seems
inefficient and wasteful to duplicate that functionality. But I concede
that the local repo workaround is not too much of a hardship, and there
are more important issues to be worked right now.
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
Re: Does Ivy really have a cache resolver?
Posted by Xavier Hanin <xa...@gmail.com>.
On Fri, Mar 14, 2008 at 7:52 PM, Brown, Carlton
<Ca...@compucredit.com> wrote:
> I researched and found enough information to get up and running with it.
>
>
> For anyone interested, you can view the patch I attached at:
>
> https://issues.apache.org/jira/browse/IVY-612
>
> I am sure there are some undocumented attributes but at least you can
> get started with this.
>
> One particular question I have is: Now that there are multiple caches
> possible in beta-2, will it be possible to assign a particular cache to
> a CacheResolver? In my testing, CacheResolver accepts the assignment
> of a cache attribute, but it does not use it.
CacheResolver has been introduced quite a long time ago and never
documented because it wasn't supposed to be public. I'm still not sure
it's a good idea to use it... IMO, Ivy caching mechanism should be
strong enough to avoid the requirement for a cache resolver, at least
at resolve time. With the addition of dynamic revisions caching in
beta 2, now Ivy cache has all information necessary to be able to
perform a resolve from the cache, without actually requiring to use
the cache resolver. This may require some improvement, like accepting
to use dynamic revision resolution cached data even when they have
exceeded their TTL. This could be a special resolve mode or refresh
mode. With this improvement, the last thing for which the cache
resolver would still be useful is publishing. But even in this case,
I'd prefer using a local repository with useOrigin="true": the
behavior is sligthly different, but I think this should address all
the needs covered by cache resolver which only has its root in bad
caching support and is a design flaw. What do you think? Do you see a
use case where CacheResolver is really necessary?
Xavier
>
>
>
> -----------------------------------------
> ====================================================
> This message contains PRIVILEGED and CONFIDENTIAL
> information that is intended only for use by the
> named recipient. If you are not the named recipient,
> any disclosure, dissemination, or action based on
> the contents of this message is prohibited. In such
> case please notify us and destroy and delete all
> copies of this transmission. Thank you.
> ====================================================
>
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
RE: Does Ivy really have a cache resolver?
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
I researched and found enough information to get up and running with it.
For anyone interested, you can view the patch I attached at:
https://issues.apache.org/jira/browse/IVY-612
I am sure there are some undocumented attributes but at least you can
get started with this.
One particular question I have is: Now that there are multiple caches
possible in beta-2, will it be possible to assign a particular cache to
a CacheResolver? In my testing, CacheResolver accepts the assignment
of a cache attribute, but it does not use it.
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================
RE: Does Ivy really have a cache resolver?
Posted by "Brown, Carlton" <Ca...@compucredit.com>.
OK, so after doing some digging I found that there is a cache resolver
which extends FS resolver, but I don't understand its behavior at all,
and there doesn't seem to be any documentation or unit tests on it.
All I'm looking for is some way to publish and resolve strictly to a
cache, no other resolvers involved. And preferably this resolver
doesn't need to specify any artifacts or ivy pattern, because it's
defined explicitly or implicitly by the cache definition. Does Ivy
have anything like this?
I experimented with the cache resolver, I found that Ivy will not
prohibit a resolver definition of <cache name="mycacheresolver"/>, but
will not add it to the list of resolvers. If you try to specify any
patterns or attributes, the settings task fails with a message that
there is no appropriate method to add these things.
Help much appreciated... It would really be a benefit if we could
interact only with the cache without any repository.
-----------------------------------------
====================================================
This message contains PRIVILEGED and CONFIDENTIAL
information that is intended only for use by the
named recipient. If you are not the named recipient,
any disclosure, dissemination, or action based on
the contents of this message is prohibited. In such
case please notify us and destroy and delete all
copies of this transmission. Thank you.
====================================================