On 9/11/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > > 2) Introduce a <tagdef> or <roledef> for the purpose
> > > of locating extension points as nested elements.
> but I looked at the code and realized that the type
> handling in ant would become too complicated - there
I see your point. Increased complexity is not good. But is it really
that complex? This new mechanism would only kick in when IH would
overwise have rejected a nested element, and only add lookup into a
new mapping when the current type has an add(Type) extension point.
True, their can be tricky cases when a type has both an add(Condition)
and a add(FileSelector), but that should be pretty rare, and could be
thrown out as ambiguous. It could even be resolved using the
undocumented ant:type attribute.
Ok, I dug out my old code and after digging out some of the bugs
and misunderstanding, I have modded IH, CH (componenthelper),
and <typedef> to allow "restricted" types.
These are like normal types except:
1) they are only allowed in add[Configured](Class) contexts, they
cannot be used at the top level or task containers.
2) One can have a multiple number of definitions with
the same name. IH will pick the one that matches the
add() methods in the container class. If there are multiple
matches, - for example class that has add(Condition) and
add(FileSelector)
presented with "and", IH will throw a buildexception for ambigeous.
I am not too sure this should be user visible but it can be implemented
by an extra attribute to the typedef task - restrict=yes/no default is no.
One problem is that the antlib.xml for antlib:org.apache.tools.ant would
be long and tedious when all the conditions, selectors, mappers, resources
are added.
Being long means that startup time for ant would suffer a little (the file
needs to
be parsed) and being tedious means that it would be difficult to maintain.
To solve the startup problem, I propose that we use an AntLibDefinitions
class associated
with a name-space which would contain the definitions.
To solve problem two, I propose that we use annotation like syntax:
* @ant.type [restrict="yes"/"no"] [name="whatever"]
or
* @ant.task [name="whatever"]
Where the defaults are restrict=no, name={classname in lower case without
package)
And have a task that will generate the definitions - either as an antlib xml
file
or as a AntLibDefinitions java.
I will create a bugzilla issue where I will place the diffs and task.
This will not of course be for ant 1.7!,
however we can add the @ant.type tags now for documentation?,
@ant.task is already in place for the ant doc project.
@ant.datatype is used as well - but ant types do not need to be
datatypes and not all datatypes are ant types.
Peter
It would however be nice to get something that
> allows add(Condition) or add(FileSelector) to work
> without having to extend BaseCondition or whatever
> is done for FileSelector .
Precisely. Unless I'm mistaken, this can already be achieved now by
using namespaces, and the condition antlib. So AssertTask could be
made ConditionBase independent now, no?
--DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
