As part of the ant-contrib project, I had written a task which, underneath the
covers,
used the ivy library to resolve a jar file, extract it locally in the ivy
cache, and import an
ant build script.
<ac:importurl org="org" name="name" rev="latest.release" />
The following actions would be performed:
1. Resolve the requested module using ivy's inline resolution capabilities
2. Expand the resolved .jar/.zip file to the ivy cache
3. Import the "build.xml" contained in the jar file (the imported filename
is
overridable via the "resource" attribute on the task).
In theory, it's a wrapper for 3 operations:
<ivy:resolve />
<unjar />
<import />
This gave me the capability to build re-usable build components which could
be shared amongst different projects. The components live in the ivy
repository.
As a result, it became very easy for me to have one common set of build tasks,
which could be updated across the board for all projects simply by publishing a
version of the dependency.
I realize that this is typically accomplished using an ant <import> task.
However, that
has several drawback, which i won't go into here, unless someone really wants
me to.
With the pending release of Ivy 2.0, this task will no longer work without code
changes
to account for the changes to the API from 1.4.1 to 2.0.
I'm wondering if this task might be better suited to being owned by the Ivy
project itself.
I am more than willing to donate the code to the Ivy project. As the
ant-contrib project
is published under the Apache 2.0 license, i don't see any issues with this.
Any thoughts from the dev team?
----
[EMAIL PROTECTED]
"Once you start down the dark path, forever will it
dominate your destiny. Consume you it will " - Yoda
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
