Tim Dawson wrote:
Stefan writes:
I would prefer (1) if we made it a normal target.
Which would be the old unmodified "no tasks outside of targets" which received a -1 by Conor ...
Well, he has to -1 it again now, doesn't he?
OK.
-1.
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. 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 don't think a "-1000" counts for the next thousand times the vote is brought up. :-)
I don't think I -1'd it originally but vetos cannot, in general, be overruled.
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. Some things (not necessarily many) need to be processed and validated in the parsing stage. This is why "target" and some other keywords ("projectref", "include", whatever) will be coded into the parser because it allows the parser to contruct the build object model. Everything that is not specifically recognized will probably be collected into a model component that supports arbitrarily nested XML elements. This will of course be used for tasks/types but may also be used for other constructions which need to be processed in the execution phase. So, there should be sufficient extensibility in the model for other elements without making the parsing phase some sort of stripped down DOM builder or taking on the "everything is a task" view.
option (1) -1 but not necessarily against <init>, init="" option (2) +1
option (3) +0 - can be done in execution stage only and not necessary if (2) goes.
Conor (Happy to discuss further).
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
