ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: IntrospectionHelper request
Date Fri, 11 Jan 2002 01:05:32 GMT
From: "Peter Donald" <>

> On Thu, 10 Jan 2002 18:22, Jose Alberto Fernandez wrote:
> > From: "Peter Donald" <>
> >
> > > On Wed, 9 Jan 2002 19:40, Jose Alberto Fernandez wrote:
> > The problem I have with this is that it allows a Task to violate all and
> > any rules. 
> precisely. It is the "escape and do whatever you feel like" bit so that 
> people can do whatever they feel like doing and still run it inside ant with 
> out messing up the container for other tasks. 
I think I am against unbound flexibility. I would argue that the job of the Configurer
(to give it a name) is to maintain a minimum set of rules of behaviour.
Once you start given away control in an unbound way there is no way back.
Remember, that part of the aim in ANT2 is to allow people to write and distribute
their own tasks. We cannot just say that we would tr to keep a lit on it.

> In many ways this is bad but because of the somewhat higher barrier of entry 
> it is expected that it will very rarily be used except when most needed. 

Never disregard the ability of programmers to make use of every opportunity
for mischief ;-)

> >I think the container (via an enhanced Introspection) needs to
> > be the one in control here. By enhanced I mean that the work is not only
> > based on Class introspection, but the Task is allowed to say what is
> > willing to accept (what we have been talking about DynamicTask providing
> > their own introspector).
> I await your fleshed out proposal. I haven't found anything that is both easy 
> and as flexible as the described approach.

OK, I finally took a quick look at some of the interfaces of Myrmidon and
here is a more concrete proposal. So what I am saying is to allow Tasks
to provide their own ObjectConfigurer to use by the DefaultConfigurer.

Instead of passing the configuration to the object if the Task implements
Configurable, what you do is ask the Task to provide an ObjectConfigurer
if the Task defines DynamiclyConfigurable (for example):

    interface DynamiclyConfigurable {
        ObjectConfigurer getConfigurer();

For what I see of the the definition of ObjectConfigurable is should be quite easy
for an object to define its own methods, and if we provide a few predefined helper
classes, the whole affair could be even more trivial.

> > My point above should solve the "flexibility" problem. I would like you to
> > explain why you think add(MyInterface) is not reliable. If it isn't then we
> > have a more fundamental problem here because if it is unreliable for Tasks
> > then it is unreliable for the other roles also.
> Essentially add() fails because you can not have two adds in the same 
> element. The whole question of order is one aspect of this - but even if you 
> work this out then there is still a greater problem.
> Take the following
> <blah>
>  <a/>
>  <b/>
> </blah>
> Now lets assume it has two adds. The first run we we look up Role1 for "a" 
> and it is found and so we add the reult instance to adder 1. We look up "b" 
> in Role1 but it is not found, we do find it in ROle2 and thus we add the 
> instance to adder 2.
> Now some outsider comes along and registers a new type of Role1 named "b" 
> (which is easy to do by just dropping librarys in right place). Now when user 
> reruns tasks both "a" and "b" will be added to adder1.

Well, this is one reason I do not like auto-installation of libraries. One should declare
the libraries that one want to have available to the build. As with java extensions
when you allow auto-installation, the result is unpredictable behaviour.

As for clashes, there are several things that need to be done:

1) Buildfiles should execute on a stable environment i.e., no auto-install
but all libraries (appart from core) should be declared on the buildfile.

2) The container should detect clashes by looking at all possible role registries
that may apply. This can be done quite efficiently.

3) A clash resolution mechanism should be provided, posibly using aspects to
indicate the expected role to be used in a particular occurrance.

> > > In any case TaskContainers need to be treated differently as no task can
> > > ever get access to another Task instance - they only operate on the
> > > TaskModel. (They pass the TaskModel to the container which executes the
> > > Task).
> >
> > I really do not think special treatment is necessary.
> well you are in the minority - most of the proposals have that idea and it 
> was voted on ages ago IIRC :)

We have voted for and against so many things that are now part of ANT that I do not think
the issue should be the vote but the technical merit of the approach. And then we can
vote again (the commiters I mean).

> >
> >     <role name="task" interface="org.apache.ant.Task"
> >              proxy="org.apache.ant.TaskModel"/>
> >
> > So now, for a method of the form add(org.apache.ant.TaskModel), we would
> > know is role "task", we would create an instance of the Task, and use it to
> > construct a TaskModel which will keep the model information and then call
> > add(taskModel).
> Im not sure what the advantage of this. How is it any different to 
> <role name="task" interface="org.apache.ant.TaskModel"/>

The diference is that here you are indicating that all <task> should implement
TaskModel, which is wrong. <task> implement Task, but the container needs
to interpose a TaskModel between the two.

> > Now TaskModel needs to be loaded with the XML model, so it can configure
> > its task at the right time, but that can be accomplish by generic behaviour
> > on the introspector and not by something special to TaskModels. That means
> > that other roles or proxies can do the same.
> In myrmidon the Configuration is the TaskModel 

Well, what I am refering to is how the TaskModel captures the XML that defines it.
We are probably talking about quite similar thins here. The only difference may be
that for me TaskModel contains only the little piece of the XMLModel that corresponds
to a particular Task (to each add(TaskModel) operation) and not one object for the
entire Task being configured (which iswhat you do with Configurable).

I really do not thing Myrmidom is too far from what I am proposing.

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message