ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Duncan Davidson" <>
Subject Re: Some Thoughts on Ant 1.3 and 2.0
Date Wed, 01 Nov 2000 15:26:31 GMT
On 10/31/00 1:39 AM, "Stefan Bodewig" <> wrote:

> JDD> I wouldn't mind planning on seeing 2.0 on the order of first
> JDD> quarter next year. It's not something that has to happen sooner
> JDD> -- just better.
> Oh, yes, I don't say we need to hurry to get 2.0 out. When talking
> about shorter release cycles I was thinking of Ant 1.3 which I'd love
> to see happen somewhere around Christmas maybe. If we'd fix some
> serious bugs, we should also go out and do a maintenance release ...

Sounds good.

> JDD> Actually, I'd rather break with the past and just say that if I
> JDD> have a property defined at a upper level, and it's not
> JDD> reassigned at a lower level, then you get the upper level -- but
> JDD> if it is reassigned at a lower level -- you get the lower
> JDD> level. It's simple and to the point.
> The problem I see with this approach (apart from breaking many, many
> builds of course) is the one of <available> and <target if=> where a
> property could be set (coming from a upper level) that you wouldn't
> expect to be set.
> Conor's approach to explicitly list the properties you want to pass
> down to a sub project might be even simpler and clearer.

Maybe, but the approach as stated would map exactly to how env vars work in
Unix with processes/subprocesses. I'd rather map to this than have more
machinery in place that tells what variables are passed where.

>>> (2) Do we want mutable properties or not?
> JDD> Yes.
> My, my. We should have come to this five months ago ... I must admit I
> hardly recognized that properties became immutable back then.

But -- properties should only be scoped at the project level -- and defined
at the project level.. :)

>>> (*) Some kind of front end to satisfy the more complex needs of
>>> some users.
>>> This is where I'd see support for enhanced conditionals and other
>>> things. To quote Duncan: a tool that would be "to Ant what
>>> configure is to make".
> JDD> Yep. In fact, I'd really be for making Ant simpler again in the
> JDD> presence of a antconfig that could take care of things on a
> JDD> platform or other basis.
> You mean even going to the extend to drop the if and unless attributes
> everywhere? This would make using antconfig almost a requirement for
> using Ant and I don't think I'd like this.

I'm not sure if I'm talking going that far back or not.

James Duncan Davidson                              
                                                                  !try; do()

View raw message