Jose Alberto Fernandez wrote:
Just to put closure in my list of peeves about <import>,
I really think we need a way to define "private" targets.
+1, one should be able to write an importable build file that has some exported targets - but internally uses targets that do not get overwritten accidently.
Peter
Now, for this to work properly, you need:
1) A way to mark a target as private. 2) private targets must be ignored by targets of the same names on other
points in the hierarchy. 3) Depends on a private target must be resolved by the correct instance of the target.
So lets assume the following syntax:
<private-target name="..." depends="....">...</private-target>
foo.xml <project name="foo1"> <target name="compile" depends="setup"><echo message="compiling"/></target> </project>
bar.xml <project name="bar1"> <import file="foo.xml" as="f"/> <target name="build" depends="setup"><echo message="building"/></target> <private-target name="setup"><echo message="prepare build"/></private-target> </project>
baz.xml <project name="baz1"> <import file="bar.xml" as="b"/> <target name="setup"><echo message="prepare compile"/> </project>
ant compile prepare compile compiling
ant build prepare build building
Here: foo.xml is like an abstract project which does not define "setup";
bar.xml's setup is private to bar1 and will not be used by the
dependency in foo1
baz.xml overrides (defines in this case) the setup target used in foo1
but not the one in bar1.
The rewriting rules are a bit tricky, because for every private target you need to use a new "private name" for it, and change all the occurencies in dependencies on that file of the name, for the new name.
Seems actually doable.
Jose Alberto
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
