From: "Peter Donald" <[EMAIL PROTECTED]> > On Fri, 19 Oct 2001 21:40, Jose Alberto Fernandez wrote: > > I also think that if we adopt this proposal, the resulting pattern for > > buildfiles will be having all targets expressing dependency on one "init" > > target. If people do not think so, I would like to see one useful buildfile > > for a project with targets that do not require the usage of any properties. > > So at the end we will finish with a very redundant pattern. > > Some people like the explicitness of it. > Just because some people like it, it doeen't mean it is right. The same would apply if we were talking about most people (so this is kind of a mute point). If I remember correctly, at some point in 0.x, ANT properties were not allowed outside targets and people yelled and complained until it was changed. What this means is that there is a usability issue involved here that we need to take into considerarion. In every project I have seen, there are a (ussually) very large number of properties and other declarations that have a global nature. There is little reason to force users to check any possible dependency graph in order to make sure all evaluation paths start at "init". It is a waist of the developer time.
> > Finally, what is the meaning of "ant target1 target2"? In the current > > implementation, the "init" target from which "target1" and "target2" depend > > will be executed twice. Which is probably not what we want ant to do, it is > > certaintly not what we mean when we put things outside a target. > > Why not? That is not what happens today. So it cannot be what they mean ;-) Are you trying to tell me that it is desirable in the above example for property declarations, library loading, project imports to be loaded more than once? I really doubt it. Even the way <antcall> works today, seems like 90% of CPU processing is waisted on <property> failling to be re-declared. But that is a separate issue. > > > Not surprisingly, this is the one I prefer :-). The point here is that > > there are certain tasks whose Job is to declare things to be used in the > > rest of the project those include <property>, <taskdef> and <typedef>; and > > in the future they may include things like the proposed <antlib> and even > > <projectref>. There is no reason for the core to have to be aware of such > > things since tasks can perform the work just fine without ProjectHelper > > being involved. > > I don't see *def as being required in top level at all. projectref and import > (antlib) functionality have to be handled separately anyways so those can be > ignored. > I really do not see why that has to be so. I already provided an implementation for <antlib> that does not require any knowledge from the core. And I would suspect something similar could be done with respect to <projectref>. Granted, it will all depend on what we mean by these operations. But it is obvious that there is a sound, useful and clear implementation that do not require <antlib> to be more than a task. And if <antlib> it is not a task, you would not be able to load a library created as part of the build project itself (or is your idea that that needs to be forbidden?). > > As the discussion on <antlib> will bring to mind, we have not exausted the > > list of tasks that can be declaring things on a buildfile. And hence it > > makes more sense to provide ways for a generic mechanism that does not > > require changing core everytime. > > see above. *def should not be required at all unless you are creating tasks > in same file you use them in which case you can't have it at top level > anyways. > Why do you think that the only things that one may want to declare are what we have today? I could think of several others, but the real point is that we should not stablish limitations that are not needed. > > This I think is the worst thing we could do. It produces comical situations > > like <taskdef> being allowed outside targets but <typedef> not being > > allowed, I guess it was forgotten. It will only produce inconsistent usages > > and breaks the simetry between core and user defined tasks. In other words > > it creates a two tier system of tasks, there is no reason for this at all. > > I disagree. The only real things needed at top level is config data (of which > *def is not part of). We can easily restrict this based on intelligent > decisions now. > I disagree. I guess the difference is that I do not want to prejudge what kinds of tasks or usages of ANT can or cannot be done in some future. While a hardcoded approach will limit anyone from using ANTs engine for other worthy purposes. I see no reason for such restrictions. Jose Alberto
