--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hi,
>
> before becoming lucky by picking the best two weeks
> of Northrhine
> Westfalia's school holidays as our family vacation
> time I committed a
> change to the <ant> task that added an
> alowNativeBasedir attribute.
>
> When this attribute has been set to true, the
> basedir of the called
> project will be the same that it would be when
> invoked from the
> command line (i.e. the dir attribute and the
> inheritall properties are
> ignored for this).
>
> Not only is this what one might have expected to be
> the default
> behavior of the Ant task, it is also part of my
> attempt to fix
>
<https://issues.apache.org/bugzilla/show_bug.cgi?id=30569>.
>
> Dominique stumbled over the commit and commented on
> the bugzilla
> issue. Like him I prefer to keep any discussion on
> this list (I never
> intended to discuss the change in bugzilla but was
> keeping a record of
> the changes I made).
>
> <ant>'s dir attribute is also used to actually
> locate the build file,
> so in certain situations it may be valid to set both
> attributes on the
> same task.
>
> Currently I'm stuck with implementing
> allowNativeBasedir (or whatever
> its final name may be) in situations that involve
> more than one layer
> of <ant> tasks - which is what we have in the
> bugreport: a build
> invoked via <ant> in turn uses <subant> and the
> later doesn't set the
> expected basedirs for the (grand)child builds.
>
> Let's say we have:
>
> A.xml:
> <project basedir="A" name="A">
> <ant dir="foo" antfile="B.xml"/>
> </project>
>
> B.xml:
> <project basedir="B" name="B">
> <ant allowNativeBasedir="true" antfile="C.xml"/>
> </project>
>
> then project B will have a basedir of "foo" when run
> via project A
> (which is fine since it is documented that way).
> The problem is, so
> will have project C because of the way we
> implemented "basedir
> inheritance".
>
> When project B is created we set "basedir" as an
> "inherited property",
> i.e. a property somewhere between a "user property"
> and a "normal
> property". Even with inheritall="false", <ant> will
> invoke
> copyInheritedProperties() to copy over all inherited
> properties from
> project B to project C - and in the presence of the
> property "basedir"
> project C will ignore the basedir attribute of the
> build file.
>
> We can't simply change copyInheritedProperties'
> signature in order to
> say "but skip basedir" because it would break
> PropertyHelper's public
> API (and this is an explicit extension point). At
> the same time
> PropertyHelper doesn't provide an API to iterate
> over inherited
> properties so we can't emulate copy... from within
> the Ant task.
>
> Right now I see these options:
>
> * break the PropertyHelper API (we may have already
> done so for 1.8.0,
> I'm not sure)
>
I think the public API is preserved but deprecations
have been marked. Since the API was documented as
being unreliable and in-flux, and because the only
well-known consumer of the API
(AntXtras/wascallywabbit) has failed to respond to
promptings for opinions on the subject, I'd call it
fair game.
-Matt
> * break ProjectHelper's API so we can tell it to
> ignore the basedir
> property and read the attribute - yet another
> explicit extension
> point of Ant.
>
> * Have the Ant task peek into the build file and
> read the basedir
> attribute itself - and perform the same logic of
> ProjectHelper2.
>
> I don't like either approach. Any other idea?
>
> Not making basedir an inherited property while still
> retaining the
> (sometimes strange but documented) behaviour of
> <ant> doesn't look
> attractive either.
>
> 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]
