Going to the old discussions in how to approach this issues,
the thing that bother me most, is that in order to get access
to an imported target I need to know the name given to the project
on the file that did the import.
This in my opinion contradicts the hidding rules of OO programming.
I should not need to know about the internals of an imported object.
It also means that I have to coordinate all the files I may directly
or indirectly import so that there is no project name clashes.
I would advocate to allow the importer the specify the aliasing name it
wants to use for the imported things, so one has something like:
foo.xml
<project name="foo1">
<target name="compile">...</target>
</project>
bar.xml
<project name="bar1">
<import file="foo.xml" as="imp1"/>
<target name="barcompile" depends="imp1.compile">...</target>
</project>
baz.xml
<project name="baz1">
<import file="bar.xml" as="imp2"/>
<target name="compile" depends="imp2.barcompile,
imp2.imp1.compile">...</target>
<target name="cc" depends="imp2.compile">
<!-- Same as imp2.imp1.compile by inheritance -->
</target>
</project>
The point being that the user of the imports is the one deciding how to
refer to
the targets in its own local file. For BC, is no 'as' attribute is
specified we
can use the imported project name.
At implementation, what we need to do is for every imported target,
rewrite their names
and add an empty target with the original name, if not already
overriden.
I think that is all that is necessary.
Jose Alberto
> -----Original Message-----
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Sent: 12 May 2005 20:35
> To: dev@ant.apache.org
> Subject: Re: [Bug 28444] - Import: Target Handling Bug
>
>
> On Thu, 12 May 2005, Peter Reilly <[EMAIL PROTECTED]> wrote:
>
> > The target gets renamed if there another target of the same
> name, but
> > not otherwise - how can one write a proper reusable import
> file using
> > the rename feature in this case?
>
> I'm strongly +1 for at least providing renamed aliases for
> all targets, independent on how we achieve that.
>
> > The fix will have a small overhead - the target object needs to be
> > cloned and given a a new name, whereas the current code
> just renames
> > the target object.
>
> Do we really need to create a complete clone? Can't we
> achieve the same with a more lazy approach?
>
> Turning Matt's idea around:
>
> (1) Target "foo" is in project "bar".
> (2a) There already is a target "foo" from the file that imported
> "bar", use the current code, we are ready, "bar.foo" is there.
> (2b) There is no other target "foo" yet. Create an empty placeholder
> target "bar.foo" that depends on "foo".
>
> If then later a target "foo" is found in the importing buildfile,
> replace the placeholder "bar.foo" with the initial "foo" target.
>
> Wouldn't that work, stay backwards compatible and hide "bar."
> whenever possible?
>
> Stefan
>
> ---------------------------------------------------------------------
> 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]
