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="emma_ant.properties">
<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
-Dorg.eclipse.eclipseresolver.osgiurl=http://eclipse.org
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
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
