On Mon, Apr 7, 2008 at 4:56 PM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> 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. Sorry, no pointers to give, jar caching should work if you don't bypass the default download method implementation in BasicResolver. Don't have time to look back to your code, but add a breakpoint in the download method and see how it works with your resolver, and you should see what's wrong about that. > > > > > 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? Well, the problem is not strictly the same. In one case the resolver is actually executing the ant script. In the other case, Ivy is only downloading bytes, and you decide to execute them. But you can take care of executing them only in a sandbox, or in a virtual machine with no rights, or whatever. Ivy is not responsible for what you do with the downloaded artifacts. I don't mean there is no security risk though, I just say it's different. 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 :-) Or you can use something else than xslt, like some java code. It's not pretty, but we already do this frequently in Ivy: rewrite in Java what some libraries already do, simply because we don't want to hit the chicken and egg problem. If the language is simple, writing some java code to parse it and write the ant script can be pretty straightforward. > > > 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? Mainly test and documentation. By test I mean some automatic test, based on junit, and using a repo packaged with Ivy sources (probably accessed with file: URLs), as we do for almost everything in Ivy. This is the only way to get something included in Ivy core, because once included it has to be maintained, and maintaining stuff without automatic tests is a pain. Then you also need to convince the committer team about the resolver usefulness. I like the idea, and I think I'll defend the inclusion if I see at least a beginning of growth of a public repo using this resolver. Xavier > > > Thanks, > -Archie > > -- > Archie L. Cobbs > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
