2008/4/7 Archie Cobbs <[EMAIL PROTECTED]>: > On Mon, Apr 7, 2008 at 10:31 AM, Xavier Hanin <[EMAIL PROTECTED]> > wrote: > > > 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. > > > > I just realized that this is not really a problem, because we can delay > the XSLT step until when we run "ant" (i.e., make that step part of the > build.xml we generate), and <xslt> is a "core" ant task. > > > 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. > > > > Yes I agree unit tests should be a requirement. > > Regarding security, I've made an initial version of the XSLT. See attached > files for (3) sample "builder XML" for TestNG, (2) the XSLT, and (3) sample > build.xml output. > > There is a tradeoff between security and flexibility. I decided to allow a > handful of basic ant tasks like <move>, <copy>, <zip>, <unzip>, etc. but > otherwise everything is "controlled". > > Let me know if you think I made the right tradeoffs here. > I really like it! It's simple to understand, powerful enough yet under control. One thing that would be nice to ensure a good deal of security would be to allow only relative paths in the file related operations. This would ensure that the module builder has only access to a very limited part of the filesystem.
I also like the fact that you make sha1 mandatory on the resource element. The drawback is that it means that we won't be able to download something which has no available sha1. One thing which really needs to be done IMHO is the maven import operation. Many artifacts are available on maven repository, so I think good support for importing artifacts from maven would be great. If we provide the org, name and revision values to the build file or the xslt, something as simple as <m2resource qualifiers="default,source,javadoc" /> could be enough when we use the same org/name as maven groupId/artifactId. In other cases it could be <m2resource groupId="com.acme.foo" artifactId="foo-bar" qualifiers="default,source,javadoc" />. Maybe we should put qualifiers as subtags to allow defining expected sha1 for each artifact. This would be converted in a download + checksum check + move to artifacts directory operation. What do you think? Xavier > > > Thanks, > -Archie > > -- > Archie L. Cobbs > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
