ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@bost.de>
Subject Re: Some Thoughts on Ant 1.3 and 2.0
Date Tue, 31 Oct 2000 09:39:01 GMT
>>>>> "JDD" == James Duncan Davidson <duncan@x180.com> writes:

 JDD> On 10/27/00 5:29 AM, "Stefan Bodewig" <bodewig@bost.de> wrote:

 >> I feel we should be prepared to have a Ant 1.3 release (or 1.2.1
 >> or similar) and maybe even releases following that (though I hope
 >> not) to address this - personally I'd prefer to get to a shorter
 >> release cycle than we had.

 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 ...

 >> This means we'd need to defer all things that could break older
 >> environments to a final step from Ant 1.x to 2.0, using a branch
 >> for that if necessary.

 JDD> Instead of a branch, I'd like to see it in an ant-2.0
 JDD> workspace.

That's fine with me.

 >> What I'd like to see for 2.0 
 >> ============================
 >> 
 >> (*) Switch to JAXP 1.1 and SAX2.

 JDD> Actually, I'd like to implement a mini parser that just knew
 JDD> Ant's particular syntax and remove the need to depend on
 JDD> external libs.

No, please don't. There are a couple of classes that rely on the
presence of the DOM classes for example (XmlLogger or the XML result
formatter of junit). I think it should be save to assume that th DOM
as well as the SAX classes are present when writing tasks.

 >> (*) Change of the property system one last time
 >> 
 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.

 >> (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.

 >> (*) 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.

Stefan

Mime
View raw message