ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: Defining a custom ToolsResolver
Date Tue, 08 Apr 2008 16:07:19 GMT

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

Tools could be runtimes like Python and Perl, utilities like zip tools,
internal tools, etc. We have a large number of these that are used in
our build environments. We currently have a custom script (which we're
considering replacing with Ivy) that checks an XML file for the tools
and their versions required and tests that they are available.

We check the versions by assuming the tool is available on the PATH and
running the tool with a tool-specific argument that will print out the
version string. This output is captured and parsed to extract the
version. If an Ivy resolver could do the same thing but with adding all
of the versioning and matching support it already has it would be very

 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.

If we defined our tools as modules with no artifacts, will there be some
resolve operations that will simply not be called? What does Ivy
consider a resolve operation to cover if there are no artifacts to be

>> thanks
>> paul
>Xavier Hanin - Independent Java Consultant 

View raw message