[Stefan Bodewig <bo...@apache.org>]

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)

* 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

Re:

[Matt Benson <gu...@yahoo.com>]

--- Stefan Bodewig <bo...@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