ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Defining a custom ToolsResolver
Date Tue, 08 Apr 2008 07:38:56 GMT
On Mon, Apr 7, 2008 at 7:40 PM, <> wrote:

> One use case we are looking at is using Ivy to implement dependency
> checking on the set of tools and their versions that our toolkit
> requires. For this I would imagine some kind of custom ToolsResolver
> would be needed, but based on my previous questions about custom
> resolvers, it seems there is quite a strong dependency on file-like
> objects, downloading, caches and so on.
> Does a tools resolver make sense and how might it best be implemented?
> There would be nothing to download but resolution would involve running
> each tool in a certain way to check its version (at least that is how we
> implemented our current checker which is less flexible). In this case
> would it be more appropriate to derive from AbstractResolver? Is it
> important to still have some kind of custom cache class also?

I'm not sure about what you mean about tool checking. What is a tool in your
environment, and how do you check it is present / has the good version? Ivy
relies on the concept of an artifact being a resource that needs to be
accessible on your filesystem after the call to resolve (to allow some post
resolve tasks like cachepath to work properly). But you can define modules
with no artifacts at all, only metadata. If you generate the metadata from
something like local machine environment in your resolver, you don't need
any file object at all. In this case extending AbstractResolver may make
more sense, since it's pretty far from what resolvers usually do.


> thanks
> paul

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message