ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: <ant allownativebasedir="..."/>
Date Fri, 08 Aug 2008 15:51:24 GMT

--- Stefan Bodewig <bodewig@apache.org> 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:
> dev-unsubscribe@ant.apache.org
> For additional commands, e-mail:
> dev-help@ant.apache.org
> 
> 



      

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message