Hi, 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 "org.apache.tools.ant.taskdefs.Javac". 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 etc 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 ways. 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 mail). Votes/Thoughts? Cheers, Pete *------------------------------------------------------* | "Computers are useless. They can only give you | | answers." - Pablo Picasso | *------------------------------------------------------*
