Yes, this is ok for me. I'm more than willing to submit the code to the list and let someone else work out the commit details. I'll have to write test cases as well, as my current test cases for this are executed manually. That being said, i make regular use of the task, so that is some measure of comfort with it's stability :)
I can very easily draw up documentation, though I'm unfamiliar with what format will be easiest to integrate with the current ivy build (no sense i me writing document in a format where someone will have to convert it to xdocs or something else). Any help on that would be appreciated. Thanks. ---- [EMAIL PROTECTED] "Once you start down the dark path, forever will it dominate your destiny. Consume you it will " - Yoda ----- Original Message ---- From: Xavier Hanin <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, October 15, 2007 1:20:43 PM Subject: Re: Ivy task to import common build tasks On 10/15/07, Matthew Inger <[EMAIL PROTECTED]> wrote: > > 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? I like the idea behind this task, and think it could fit in the picture of Ivy. So I think moving this to the Ivy project can be nice. We have to think about several things though: - since you are not a committer on Ivy (yet), you will have to submit patches if you later want to improve the task. Is this ok for you? - do you have documentation and unit test for this task? Documentation is mandatory, and unit test are highly appreciated :-) Thoughts? Xavier ---- > [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/ > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://incubator.apache.org/ivy/ http://www.xoocode.org/ ____________________________________________________________________________________ Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
