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 Wed, 09 Apr 2008 08:38:56 GMT
On Tue, Apr 8, 2008 at 6:07 PM, <> wrote:

> >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
> useful.
>  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
> found?

It's simply the download method that won't be called on your resolver. So I
think it fits your needs very well: create a custom resolver which in its
getDependency implementation actually perform the test to see if the tool is
present or not. If it is, it can return a ModuleDescriptor built in memory
(no need to have an Ivy file for it), which declare no artifact at all. Then
Ivy won't ask to download any artifact, and you're done.


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

Xavier Hanin - Independent Java Consultant

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