Conor MacNeill wrote: > I think there are a number of reasonable reasons for having global > properties. First of all just about all current Ant build > files use this > pattern. They could have used "init" targets but most people chose to > use global properties. This is true even when there is some > other init > tasks that get done such as making directories. Apart from being an > established usage pattern, I think it is also a usability > issue. When I > look at a buildfile for the first time I can see pretty much straight > away what are the "control points" for the build - "OK, I can turn > deprecations on here, change the build area there, etc". > These control > points are important because they will be the things I > override from the > command line or from <ant> calls when I use this buildfile.
> Moving this declaration into a target will make that less > obvious. I've typically used a separate properties file to handle all my settings because the buidl files get so damn big, and then I just have one <properties file=> tag at the top, but I can see this causing a maintainability problem for other usage patterns. And since my #1 concern is always maintainability, I retract all my comments that advocated disallowing tasks as siblings of target. There still is the issue, however, of determining what tasks can be siblings, and making that a heck of a lot clearer to everybody than it is today. Perhaps separating these from "built in tasks" in the docs? > That > isn't to say I am against an <init> element or even an init > attribute on > the project. I'm not that keen on the latter as it causes > surprises when > it has depends attribute. Even Bevan's definition > > > The "contract" could be simply that the initialise target > always gets > executed first, reguardless of what other targets are invoked. > > fails in the face of a depends attribute. That can be overcome, of > course - just depends how mucgh support you want to do on > ant-user. So I > see the issue of top level tasks and an init solution in > whatever form > as not being necessarily mutually exclusive. I think if we are careful with the wording in the docs, this concern be alleviated... if instead of saying "always gets executed first, regardless of what other targets are invoked", we say "is executed prior to any named (or default) targets", this shouldn't make it too confusing for users, who, after all, put the depends in that target in the first place. Having an <init> element is fine too, I just prefer init= because it matches the default= pattern. > > Someone had a problem with this because what if "getReady" had > > depends="foo". But I didn't really think that would be > much of a problem. > > Another issue that was raised that I don't quite understand is that > > supposedly preprocess/validation requires top-level tasks. > I mean, wouldn't > > it be possible to just execute the init target, and then > validate all the > > other targets? this is effectively what happens if you have > top level tasks. > > > > > In Ant2, we want to strongly separate parsing from execution. In my > view, parsing will contruct an object model of the build file > which will > be handed to the execution part of Ant. There will no effective > communication between these two phases apart from the build model > itself. So you're saying that Ant2 will deprecate the ability to compile and define a new task in the same build file? We do this in some of our applications and its pretty darn useful. I think that you can separate the parse & construction of the object model into multiple phases. A target could be initialized with either a list of tasks, or with an XML DOM tree that would need to be further parsed into a list of tasks upon first execution. If the desire is to provide validation of the XML file, why not just use namespaces and DTDs or schemas? (ducks and runs for cover...) Tim -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
