On Mon, Apr 7, 2008 at 2:56 AM, Xavier Hanin <[EMAIL PROTECTED]> 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 work... 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? Thanks, -Archie -- Archie L. Cobbs
