My 'itch' is to have pluggable support for component creation. If nobody
-1 the ComponentHelper - then any antlib can be implemented as an optional task. I'll probably be ok with any "official" solution ( if
it isn't too complex ), and probably I'll do my own experiments.
Having a simple ComponentHelper plugin that uses the XML namespace to
load a simple properties descriptor is one reasonable solution. Certainly
not the only one.
I'll check it out.
1. If a namespace will be used to resolve conflicts - it will be XML namespace ( i.e. we won't invent our own ).
Ok, +1, let's use XML namespace to define task/type namespace.
2. Existing files will not have to change. ( i.e. the default namespace will be used for the core tasks ).
Obviously :-) +1
3. If you don't need namespaces, you'll not have to use them. I.e. if you have a simple project and use few libs - you can still use the simpler syntax.
what is the "simpler syntax"? You mean no namespace qualifiers? How do you see both these mechanisms working at once? - defining all tasks in the default namespace and ignoring collisions?
This means the build file depends on the user's config to some extent. One user has no colision and uses <deploy> whilst another does and get the wrong <deploy> defined first. Not sure this is good.
The xmlns syntax is well defined - the only issue is the semantics of the
URI. Some people have strong opinions on that. My (strong:-) preference is for a URI that does have some semantics - i.e. it can be resolved to a java package. Some form of catalog can resolve this to URLs or something
else.
We need to have some mechanism to match the URI to a jar, whatever the URI format is. At this stage my pref would be to use a standard HTTP URL from which the library may be downloaded (not necessarily directly).
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
