peter reilly wrote:
> Using property files is nice but with new attributes
> to typedef (adaptor for example) it would be better to
> use an xml file/resource.
I think we already agreed on XML - there is no reason to continue
> This should be independent of using antlibs/jars or XML ns.
> Hence I think that the root element name should not be
> "antlib" as this implies more baggage.
> (Also my work in progress implementation uses an ant task
> for the xml parsing and the root element name is the task
> name ;-)).
That's what I would do too ( and why I suggested using ant xml
processing for the antlib descriptor ) :-)
What "baggage" are you talking about ? Antlib is what we are
trying to do, it would be confusing to use another name for
the root element.
>> > 1) the code to handle XML namespaces in ProjectHelper2 is
>> > not yet complete.
>> > - namespaces of attributes is not handled yet - the
>> > code uses getQName() on the attributes and does
>> > not pass the URI of the attributes to the attribute list given
>> > to
>> Easy to fix it to localname, but I don't want to get into ns +
>> attributes, let's leave it for ant1.7 :-)
>> ( or at least wait for the component creation to be done ).
> The NS standard http://www.w3.org/TR/REC-xml-names/
> allows one to do somthing like this:
> of course it is up to the ant software to understand the xml file,
> but "unsupported attribute 'class'" is not a usefull error message
> in this case.
Yes - but let's first implement namespaces on the elements.
We can add code to ignore ( for now ) attributes that are in a different
namespace than the element - that would allow various annotations or
3rd party tools.
After we see how people use namespaces - we can add more features for the
>> Attribute + NS affects the introspection.
>> > - the uris for project/target elements/attributes are not
>> > checked.
>> Project and target are "owned" by ant, you can't redefine them in
> This is true, but using namespaces one could do:
> hello world
> which is clearly wrong - but with the current code gives the
> misleading error:
> "Could not create task or type of type: target"
There are plenty of wrong things one can do :-)
We can fix the message to say "html:target" or use the URI, it's not
a show stopper.
>> > - the ns standard allows different types of software processing
>> > for the different namespaces, if this is to be supported
>> > ProjectHelper2 would need to look at the uri before handing the
>> > element to the "ElementHandler" object (see my previous e-mail
>> > on the subject)
>> Not sure I agree ( or understand ) this.
> The idea is to allow a xml ns to be used for purposes other that defining
> Unknown Elements. My example was an antdoc xml ns.
Still don't get it. PH2 creates an object tree - and various element in the
tree can access the tree and do whatever they want. PH2 itself shouldn't
be involved in this.
>> > 3) In what ns will the introspected attributes and nested elements of
>> > the new
>> > elements reside? Some of the previous e-mails assume that they
>> > belong in the antlib's namespace - but what about datatypes that
>> > extend
>> > ant's datatypes - e.g mypath. (This is assuming that the
>> > attributes/nested elements are found by introspection - for jmx:...
>> > this may not be the case - or a different Class than
>> > IntrospectionHelper may be used).
>> Those created by IntrospectionUtil - it doesn't matter, it's set by the
> It does matter from a build script point of view.
> is different from:
The first case is simple - the current rules cover it.
For the second - I don't know how could we handle it with the simple
patterns ( createPath / addPath ).
What's your proposal ? To apply the simple patterns to the local name ?
>> introspection rules. For the new polymorphic tasks - probably the same
>> rules of component creation as in top-level tasks. ( still not sure if we
>> agreed on how many lookup tables we'll use )
>> > 4) the proposed polymorphic element type substitution
>> > will need to be made ns-aware. either
>> > or the ns prefix -> ns uri mapping
>> > at the parse time when processing type="newtype" will need to be
>> > maintained.
>> Probably using the prefix in newtype would be the most intuitive (
>> ), but that will require some tricky
>> change in PH2 to implement.
> Actually I think change is easy enough. :-)
Sorry, I don't understand exactly what behavior you want.
>> > 5) Use of the ns form > > classpath.
>> What do you mean ? An antlib is a jar with a descriptor and a URI (
>> either a package name - or something else ).
> I mean that one does not need to use jars for this. The class path is
>> > To support this I would propose the following:
>> > 1: define the xml format of the definition file.
>> > I would propose a root element of "antdef" and nested elements of
>> > "typedef" and "taskdef" and a possible "description" nested element
>> > and/or attribute.
>> Or "antlib" as root element ?
> As I said above my implemation uses an ant task for this, using the same
> name for the root element of the descriptor and for a different task would
> cause interesting problems for the implementation.
>> > 4: Implement the XML ns changes to use the xml definition file possibly
>> > using a predefined filename and using a package name.
>> Not sure I understand - which part are you talking about ?
> I mean that I am making no assumtions on the location of the
> definition file, in the class path, or in the jar or in the meta-data
> part of the jar or meta inf attribute pointing to the xml file or having
> two xml files one pointing to the other....
Ok. Well - even if the NS is not used to load the descriptor, I still think
it would be good to at least recommend the package to be used as ns.
( and certainly not http:// or file:// :-)