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 Mon, 07 Jan 2002 22:20:12 GMT
From: "Peter Donald" <>

> On Mon, 7 Jan 2002 11:33, Jose Alberto Fernandez wrote:
> >
> > The examples I have are things like <ejb-jar> which need to support new
> > elements as new EJBcontainers are supported, and tasks like <condition>
> > that is suppose to allow more conditions being defined over time. The
> > curent requirement of modifying core tasks everytime a new thing is added
> > is totally unacceptable.
> agreed. Theres a whole bunch of other types aswell (ie mappers) that have 
> similar limitations.
> > A simmilar problem we are having with <javac>
> > everytime we add support for a new compiler.
> javac/jsp/etc is a similar problem however not exactly the same and not 
> something I will address in myrmidon (at least not in the near future). There 
> will still be some ugly hardcoding in here but recently Adam suggested using 
> XML format to configure the underlying services such as
> <javac ...>
>   <jikes warnings="full" .../>
> </javac>

This to me is the correct way to deal with compiler specific issues. Rather than
having some uninterpreted argument passed to whatever is underneath, we should
have arguments specific to a particular compiler. In particular I would like to be
able to define buildfiles in which I can set different options for different
compilers and at the end the option used depends on the compiler at hand,
something like:

 <javac ...>
   <jikes warnings="full"  ifavailable="true" />
   <scj optimized="no"  ifavailable="true" />

The idea here being that you can write build files that work correctly no matter
what compiler the developer happens to be using. the 'ifavailable' is just a thought
we need to think better how one goes on indicating that it only should be used
if that is the compiler made available.

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.

> However this is more radical than what I have been thinking about but it is 
> one possible solution. I have not really played with it to see whether it 
> works or not.
> > I have not seen a good solution for this issues. Upto now we are stuck on
> > requiring changing the core tasks in order for the introspector to work.
> > That should not be needed.
> It was explained the same time I explained the notion of types/roles which 
> you missed also ;) Basically it goes something like the following.
> [....]
> You would 
> first look it up using the standard mechanisms (add/create/set/whatever) and 
> if that failed you would look for a single method like
> void add( X x );
> If X represents an interface - lets say Condition in this case - then it will 
> look up the role registry to find the shorthand role name for that particular 
> class. So in this case it will lookup org.apache.myrmidon.framework.Condition 
> and retrieve the "condition" shorthand name.
> Then it will look up the "condition" TypeFactory (where all the "condition" 
> types are registered to via the types.xml). Then it will call createType() 
> (or whatever the method is called) on the factory, passing in the name of the 
> element (in our case "and"). The TypeFactory will then lookup its registry 
> and create appropriate type (org.apache.myrmidon.framework.And in our case).
> And this And instance will be configured and passed into the task via the 
> add() method.
> I think thats basically how it went though I have not reimplemented this in 
> the latest proposal and haven't looked at it for about a year but last time I 
> did it I liked it and found it satisfied almost all of my needs without being 
> too complex.

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.

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
<classpath> for some reason only God knows ;-).

> ants scripting capability needs a complete overhaul and could be good if done 
> right - however thta is a massive task and not something I am game to take on 
> just yet. A lot of this requires us refactoring common code into a framework 
> and then creating a nice facade + documenting a particular variety 
> (javascript being my preference atm).

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.

> > > > Will Ant2 allow dynamically defined attributes/elements?  If so, by
> > > > what mechanism?
> > >
> [...]
> So the other possibility is that you pass the task it's own task model. It 
> can thus read the taskmodel/XML and then interpret it as appropriate. However 
> that can be hard to hack so we will provide some abstract class that makes it 
> simple to configure attributes/elements using the containers services. 
> Something like
> setAttribute( anObject, "key", "myvalue" );
> addElement( anObject, myElement );
> execTask( myElement );
> or whatever. These will be tuned to make things easy to write these sort of 
> tasks. 
> Now you could abuse this functionality and dynamically set proeprties and 
> throw all sorts of type safety to the wind but it is not going to be 
> something I think we should encourage.

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

Jose Alberto

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

View raw message