ant-dev mailing list archives

Hi,
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
pre-validation.
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
file.
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
org.apache.ant.Condition
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 )
{
doMagic()
}
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.
--
Cheers,
Pete
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>