ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: ApacheCon Presentation
Date Thu, 15 Nov 2007 11:59:42 GMT
Xavier Hanin wrote:
> Here's what we do in Ivy build to use emma (this is just an example):
>         <ivy:cachepath organisation="emma" module="emma" revision="2.0.5312"
>                        inline="true" conf="default" pathid="emma.classpath"
> />
>         <ivy:cachepath organisation="emma" module="emma_ant" revision="
> 2.0.5312"
>                        inline="true" conf="default" pathid="
> emma.ant.classpath" transitive="false" />
>         <taskdef resource="">
>             <classpath refid="emma.classpath" />
>             <classpath refid="emma.ant.classpath" />
>         </taskdef>
> With cleaner metadata using only one ivy:cachepath would be enough. Without
> Ivy, you can simply use a get task and build a path from the downloaded jar.
> That's what we suggest to do to "install" Ivy itself if you want to use
> clean Ant install (since using Ivy for that is obviously not an option :-)).

Right now we are half way to something that works. With an xml 
namespace, you can autoload third party tasks. But those tasks need to 
be in the classpath or specified with a lib argument.

I could imagine

-an <ivy:typedef> command that integrates retrieval/classpath setup with 
type definitions.
  Easy to do, no changes to Ant

-the ability to declare in a build file what the resolver setup is; a 
component that is given the problem of resolving antlib URLs.

We'd need changes to Ant to delegate to any defined resolver, then have 
a task like <ivy:resolver ivyconf="${root.dir}/ivyconf.xml" />; this 
would plug in a new resolver, if none was already live (if it was, tough).

You could maybe define one on the command line too, one that could be 
driven by ant properties:
ant -resolver org.eclipse.eclipseresolver 

This is something we could think of for Ant1.8

however, before we do this, we also have to address the security issue. 
All artifacts need to come with authenticated checksums. That is either 
separate (signed) MD5 sums, or we serve all MD5 sums up from an apache 
https server. without either of those, there is no way to detect 
malicious artifacts sneaking in. In this respect, the java world is 
actually behind, say the debian apt-get world.

Steve Loughran        
Author: Ant in Action 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message