On Mon, Apr 7, 2008 at 10:31 AM, Xavier Hanin <xavier.hanin@gmail.com> 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.

Thanks,
-Archie

--
Archie L. Cobbs