ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Archie Cobbs" <>
Subject Re: Open source ivy files project?
Date Mon, 07 Apr 2008 14:56:14 GMT
On Mon, Apr 7, 2008 at 2:56 AM, Xavier Hanin <> wrote:

> About the caching of build artifacts, caching doesn't occur in
> findArtifactRef, so you should add some cache code before opening the
> stream
> on the builder artifact to get it cached.

I'm not completely sure I understand how the caching of JARs is supposed to

I understand why the builder XML file would not be cached, but I don't
understand why the JAR files are not cached. It seems like the caching of
JAR files should be handled the same way as before, by the existing
superclass code.

It does look like the ivy.xml file is being cached however.

Any pointers would be appreciated.

> Another thing to clear out: security. By downloading and executing ant
> scripts, you give a lot of power to each module download. Hence checking
> that downloaded scripts are trustable is very important. By using a custom
> xml language and transforming it, security would be important at
> installation time (Ivy + roundup resolver), and less after (well, code
> download needs to be secure too for other reasons, but it's not specific
> to
> your resolver).

Yes, I've thought about this. I see a couple of possible answers:

   1. We could argue that downloading an ant file from an URL is no less
   secure that downloading a JAR from an URL. The latter is exactly what you're
   doing when you use URLRepository pointed at (for example) the maven
   repository: you are downloading code that you will execute, and you are
   placing your trust in the maintainer of the website to not do anything evil.
   The security is in the user controlling the URL. The same is true when you
   configure and use a BuilderRepository.
   2. We could add support for a "dumbed down" XML format that was safer
   than a generic build.xml file and use XSLT to style it. Then the user could
   (optionally) configure the resolver with allowAntBuildXML="false" or
   whatever if they wanted to ensure no executable builder code was downloaded.
   The "builder XML" would just get styled into build.xml after downloading. If
   they left allowAntBuildXML="true" then we would fall back to the
   existing "build.xml" method if no XML file was found.

Do you "buy" the argument in #1? The problem I see with #2 is that now we
are adding a requirement for xalan (or equivalent) to be present when ivy
runs. This doesn't work e.g. for the situation where ivy itself is used to
download xalan :-)

In any case, it is my intention to develop the XSLT required for #2 anyway,
because it will be useful for building the "roundup" online repository.

Thinking about the future... of course I would hope that some form of this
"builder resolver" code can be included in ivy itself. This would be an
important step because it would help motivate people to start contributing
to this idea of a community "ivy roundup" builder repository, and we can all
start using and sharing a common pool of ivy meta-data.

What other issues need to be addressed before this could happen?


Archie L. Cobbs

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