ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: myrmidon questions
Date Sun, 13 Jan 2002 03:27:49 GMT

On Sun, 13 Jan 2002 13:32, Adam Murdoch wrote:
> What are your plans for the <import> task and <import> directive (at the
> top of a <project>)?  Right now, they take different attributes and
> reference the library differently (the task by file path, the directive by
> base name). What do you think of doing away with one of them (the
> directive, say)?

I was actually hoping to do away with the task (I actually forgot it still 
existed). Basically I was hoping that import of type librarys for ant behaved 
in a similar fashion to import of packages for java.

import org.apache.ant.*;    ~=     <import library="org.apache.ant"/>

The reason for this is it is much easier to validate the whole build file 
before it is run (think of lint for ant). If instead you loaded types when 
you got to a specific task then it would be next to impossible to do any 

Sometimes a build file will need to load a type dynamically - the canonical 
example being when you compile a task and then use it in the same build file. 
In these cases it will still be impossible to validate the build file but in 
all/most other cases it should be possible to validate all/most of the build 

This also makes it much easier to have portable build files. For instance if 
you have the type library on Z:\ant-support\downloaded-libs\foo.ati on one 
machine and /opt/ant/extra-libs/foo.ati on another machine and 
~/antlib/foo.ati on a third machine then it becomes extremely difficult to 
have portable build files except by requiring users enter in paths into 
property files or similar.

However if instead you had a ANTLIB_PATH env variable that every user set 
once then that woul dbe much easier (assuming library names are unique). So 
rather than specifying it in 10 different build files (assuming they are well 
written build files) which may all use different property names to indicate 
the location, you specify it once by setting ANTLIB_PATH

At least thats the idea - I think we will need to experiment with things and 
see if they end up turning out like that though ;)

I think some of that stuff also needs to be redone because specifying single 
imports will load a separate ClassLoader for each import which is probably 
overkill ;)

> How about plans for the DataType interface?  Is it going to stay a marker
> interface, or were you going to add stuff to it? 

DataType was just a generic marker interface an object could implement if it 
didn't belong to any other role. If a type doesn't have a role then it 
becomes extremely difficult (ie impossible) to place it in the registry. It 
may be possible to delete it in the future .. maybe ... if we can think of a 
nice clean way of doing it ;)

> You were talking about
> having more than one data type role - want to elaborate on that a little
> more? 

Well currently ant1.x has a few sets of subtypes. For instance we have a 
bunch of conditions that extend ConditionBase, such as; And, Or, Socket, 
IsSet, Os, Equals etc. 

So in ant2 we will instead have one role 


and a few implementations that are registered for that role such as 

<condition name="or" class="org.apache.ant.Or"/>
<condition name="and" class="org.apache.ant.And"/>
<condition name="equals" class="org.apache.ant.Equals"/>
<condition name="is-set" class="org.apache.ant.IsSet"/>
<condition name="os" class="org.apache.ant.Os"/>

Now currently our ConditionTask has a bunch of methods like

addOr( Or or )
addAnd( And and )
addEquals( Equals equals )
addIsSet( IsSet isSet )

In ant2 we can replace that with

add( Condition condition )

And thus any type registered in the Condition role could be added. So if Fred 
was to come along later and add the IsServerUp type into the Condition Role 
then they could now use that inside ConditionTask.

Now other candidate Roles would be Mapper, Scanner, FileSet etc

> In particular, how would this affect the configurer, if it wanted to
> do type substitution?

Does the above cover that?

> I'd like to automate the process of defining a TypeInstanceTask task for
> each data type.  Looks like it would be trivial to use the XDoclet stuff to
> add a <task> declaration in the descriptor for each data type.  However, I
> think it would be good to keep the descriptor as normalised as possible,
> and avoid putting the <task> declaration in there.  This would give the
> container plenty of freedom to do what it wants at runtime.  What I was
> thinking of doing was add a TypeManager implementation that took care of
> either registering the task when the data type is registered, or that took
> care of instantiating a TypeInstanceTask when a "task" with the name of a
> data-type is requested.  Thoughts?

I don't like the last case but the other two (xdoclet and a "smart" 
registering TypeManager) could be interesting to work with. XDoclet would be 
by far the most flexible solution and if we end up going with that approach 
then we could almost completely automate it (have a rule that said anything 
implementing interface X that has attribute Y is registered like so).

A "smart" TypeManager could also be a good idea. Not sure - it would mean 
that everything that was a DataType would automatically be registered as a 
"task". Is that a good idea? I don't know. It is kinda neat but probably a 
bit more work and has icky magic code ala

if( o instanceof DataType )

I would maybe wait till we see how much effort/flexability XDoclet gives us. 
It may be that is easier (fingers crossed) otherwise a smart TyeManager could 
definetly work.



|  If you turn on the light quickly enough,   |
|    you can see what the dark looks like.    |

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

View raw message