Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 82584 invoked from network); 8 Jan 2002 11:37:41 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 8 Jan 2002 11:37:41 -0000 Received: (qmail 3537 invoked by uid 97); 8 Jan 2002 11:37:38 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 3520 invoked by uid 97); 8 Jan 2002 11:37:37 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 3504 invoked from network); 8 Jan 2002 11:37:37 -0000 Message-Id: <200201081137.g08BbZc26979@mail016.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Ant Developers List" Subject: Re: IntrospectionHelper request Date: Tue, 8 Jan 2002 22:34:13 +1100 X-Mailer: KMail [version 1.3.2] References: <200201070438.g074coa30412@mail012.syd.optusnet.com.au> <000a01c197c9$7c0900b0$0100a8c0@jose> In-Reply-To: <000a01c197c9$7c0900b0$0100a8c0@jose> X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 8 Jan 2002 09:20, Jose Alberto Fernandez wrote: > There is still the issue on how to define which compiler to use (i.e., the > current magic properties) and eventhough I do not fully like it, they are > quite flexible since its value can be taken from a property file and do not > require any hardcoding or manipulation of the build file itself. I am not > sure how aspects will compete with this degree of flexibility. > This is fine. The only thing I would ask (and notice I have not looked at > your code) is whether you plan to use the same mechanism for > TaskContainers. There is certaintly no reason whatsoever to have two > different mechanisms for what it is exactly the same issue. Theres no distinction between TaskContainers and other sorts of containers. However I don't think that a similar mechanism will be used. In the case of TaskContainers et all you are not dealing directly with tasks but with TaskModels - so in this case it would be much more beneficial to have the "container" passed the TaskModel and it can interpret it as appropriate. The mechanism described above is more orientated to adding a concrete implementation of a abstract type rather than adding and possibly implementing tasks according to specified rules and behaviour. If you can think of a mechanism that would be easy to support both use cases easily then I am all ears. > In particular, when compared with the implementation in ANT1.x it would > remove the limitation that forbids TaskContainers from having inside > elements other than Tasks. I would like to be able to for example specify a > task container that defines also a for some reason only God > knows ;-). Will be possible in Ant2 and it was actually one of the things I had considered (setting classPath ala gump style). If it is ever useful is another thing altogether ;) Still for other things like nested conditions in tasks or something it would be fairly useful .. > For a long time I have wanted to come up with a better concept of > scripting. To me, scripting shouldn't be use to maniputate the Project > datastructure, but instead it should allow writing tasks just like we do in > Java that can be called with different arguments in multiple places of the > build. You know like a scripting language. This also means that the model > of objects available for scripting has to change. It has to be a smaller > set of APIs that we can give guarantees of stability. Very few entry > points. > > The problems I had in ANT1 that blocked me on trying to do something are: > > 1) The fact that the Task registry contains Class instances as oppose to > some Factory. With a factory interface one could register something that > understands how to instantiate scripts, with just classes, there is no way > out. > > 2) One needs access to the Introspector. Whatever class implements the > Script object cannot be introspected to obtain the parameters of the > script, instead Introspector needs to ask the instance to tell it what is > available. How that is done, I do not care. It could be done by the Factory > (not as good); or by asking the instance for the information either the > instance saying what it supports or saying whether a particular element is > supported. I like the instance saying what it supports, but I do not care > too much. I agree and thats something myrmidon plans on supporting. > Humm, this looks a little like the Dynamic stuff we were talking. Although > I guess you are king of inverting it. Not sure. I guess, if we allow the > Task to provide ist own Introspector (with the help of some Container > service) you could eliminate only allow such manipulations to be done on > Tasks that specifically allow them, as oppose to a blank policy. (If I > understood your concerns correctly). Thats one concern however my major concern is about the flexability and ease of writing such tasks. The way it is currently now is both flexible and easy for developer (both of task and of container) while other methods have not proved to be IMHO. -- Cheers, Pete The big mistake that men make is that when they turn thirteen or fourteen and all of a sudden they've reached puberty, they believe that they like women. Actually, you're just horny. It doesn't mean you like women any more at twenty-one than you did at ten. --Jules Feiffer (cartoonist) -- To unsubscribe, e-mail: For additional commands, e-mail: