This very much reminds me of what I was doing in our build environment. I basically had a template buildfile and could override that for any project like this:
<project> <override-target name="compile"> <.../> <super/> <.../> </override-target> </project> The difference is only that I didn't implement <override-target/> as a task (top-level tasks didn't exist back then). (Similarly with <override-property/> and <override-path/>.) Instead I generated a new buildfile with XSLT (later with dom4j). The problem I had was that it was hard to control where to place the top-level tasks in the generated buildfile. But this looks like it would be simpler with a renaming <import/>. -- knut > > I'd like to take a slightly different angle on the <import> > issue by getting > some thoughts on this little experimental task I wrote. I > haven't cleaned it > up at all (lots of unused imports, inner classes etc). Anyway > it lets you > override any target in the build. e.g. This build file > > <project name="override" default="test"> > > <taskdef name="override" > classname="org.apache.tools.ant.taskdefs.Override"/> > <taskdef name="super" > classname="org.apache.tools.ant.taskdefs.Override$Super"/> > > <override target="test"> > <echo message="pre"/> > <super/> > <echo message="post"/> > </override> > > <override target="test"> > <echo message="pre2"/> > <super/> > <echo message="post2"/> > </override> > > <target name="test"> > <echo message="test"/> > </target> > > </project> >
