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. > 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? > 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. > 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. > 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. -- Cheers, Pete ---------------------------------------------------------- Which is worse: Ignorance or Apathy? Who knows? Who cares? ----------------------------------------------------------
