I have also seen something similar in the plan for ant 1.8 [1]: - import improvements (url support, searchpath support)
I don't know if it includes also searching build file into a jar. But I think that if you combine this futur demand with the ressources of 1.7, it should. What you want to do also make me thing to an idea that I have to creates ".bar" files (like we have war, ear, ...): build archive file that contains some reusable build script, some tasks and possibly some antlibs. PS: I put ant-dev in CC in order to have more info on the plan for 1.8. Sorry for the cross-post. I think it will be solved soon. [1] http://wiki.apache.org/ant/Ant18/Planning Gilles 2007/10/15, Xavier Hanin <[EMAIL PROTECTED]>: > > 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/ > -- Gilles SCOKART
