On Fri, 19 Oct 2001 23:36, Jose Alberto Fernandez wrote: > > > 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 ;-)
Actually we got some complaints about it about 6 months ago (maybe in Jan?) because one target caused the "temporary" creation of proeprty to do tests and the second run tried to recreate property but failed. > Are you trying to tell me that it is desirable in the above example for > property declarations, yes. > library loading, project imports no. But these will need to be special cased anyways. > 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 it doesn't do half the things that I would need it to do. In fact all the stuff I have been talking about ala Extensions is a container service and pushing this into the task would require that the core be fully exposed to task-writers ... thus removing the benefit of having a small container-component interface. > And I would suspect something similar could be done with respect to > <projectref>. Projectref has to reference other projects and the building of such things also requires privlidged "container" information. Pushing this into a task would unnecesarily constrain evolution because we would be forced to maintain a porous and highly coupled container-component interface. > 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 mean that in ant1 where tasks are highly coupled to container we can do it ? My answer would be so ... we are talking about ant2. > 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?). I have already answered this. > > > 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. Why not? Limitations is exactly what we should be establishing. > 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. This is an interesting perspective considering I have always been the main person pushing for a reusable core. The difference is that I don't think people should be reusing the build file format but instead creating their own special purpose format. -- Cheers, Pete *----------------------------------------------------------* The phrase "computer literate user" really means the person has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain. -- Alan Cooper, The Inmates are Running the Asylum *----------------------------------------------------------*
