ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: Defining a custom ToolsResolver
Date Wed, 09 Apr 2008 08:38:56 GMT
On Tue, Apr 8, 2008 at 6:07 PM, <Paul.Mackay@nokia.com> 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.

>
>
> >
> >Xavier
> >
> >>
> >>
> >> thanks
> >>
> >> paul
> >>
> >>
> >>
> >
> >
> >--
> >Xavier Hanin - Independent Java Consultant
> >http://xhab.blogspot.com/ http://ant.apache.org/ivy/
> >http://www.xoocode.org/
> >
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

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