ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: Open source ivy files project?
Date Tue, 08 Apr 2008 07:16:56 GMT
2008/4/7 Archie Cobbs <>:

> On Mon, Apr 7, 2008 at 10:31 AM, Xavier Hanin <>
> 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="" 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?


> Thanks,
> -Archie
> --
> Archie L. Cobbs
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Xavier Hanin - Independent Java Consultant

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