ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject [Vote] Type Registry
Date Tue, 08 May 2001 11:46:00 GMT

Another thing that I have noticed a serious demand for is Type Registries.
What is a type registry? Well in it's absolute simplest form it associates
a type with a name.

In Ant1.x we already use a type registry - task names "javac" is actually
short hand for "". I want to generalize
this concept  to cover all the sub components we have discussed so far.
SOme example sub-components that have been discussed:
* datatypes
* converters
* mappers
* filesets

So this registry would associate a shorthand string with the name of class.
In some cases the registry may also need to build an index to allow
efficient searching but we don't need this now so I won't discuss it. In
some cases the registry also needs meta-info about component (ie converter
converts from foo to bar) and again this is not discussed at this point in
time (though I will bring that up in a few weeks).

You may have realized that the type registry is broken down into groups (ie
tasks, datatypes, converters etc). There was a few proposals on how to deal
with this. 

The first proposal was to have hierarchial searching based on inherited
type. ie SO everything extending org.apache.ant.api.DataType is a
"datatype". This however requires some really really really painful
ClassLoader manipulation and I really don't want to go there ;) It is also
complex and as yet I have no usecase where the extra hierarchial
information is useful.

Thus the second proposal is to adopt a system similar to that established
with a few "services" APIs and also used extensively by Apaches own Cocoon2. 

In this system there are are "roles". SO "datatype" is a role while
"org.apache.ant.api.ZipFileSet" is a type. Many types can implement one
role. It has also proved to very extensible and doesn't require any
difficult coding (or udnerstanding) by developers or users. Hence I say go
with that one.

Anyways in conclusion a formalized "Type Registry" will form an integral
part of how I see Ant2 going. This also decouples the deployer from
whatever deployment descriptor we end up using. This means certains tools
(ie autoconf, installshield, crontasks, initab tasks, tester) could be
developed with fixed type registries or have them extracted in particular

At this stage it is not clear to me how we should deal with this with
respect to execution stack hierarchy (ie when calling subprojects) so for
the moment I say we leave it open and experiment. Whether Registrys are
inherited, replaced or global is thus not an issue with this vote.

I am also not requesting a vote on how we transform the "type" into an
instance as that involves tricky classloader stuff which I will leave to
another vote ;)

Both of these issues will however be transparent to task writers as they
should be hidden behind a facade (the TaskContext I proposed in the other




| "Computers are useless. They can only give you       |
|            answers." - Pablo Picasso                 |

View raw message