>>>>> "JDD" == James Duncan Davidson <[EMAIL PROTECTED]> writes:
JDD> On 10/27/00 5:29 AM, "Stefan Bodewig" <[EMAIL PROTECTED]> 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
