ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: Roles (was: antlib)
Date Mon, 12 May 2003 08:59:33 GMT
On Friday 09 May 2003 04:08, Costin Manolache wrote:
> 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
> adding arguments.
>
> > 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.

The "baggage" is that "lib" is normally associated with
jar files.

>
> >> > 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:
> >
> > <project  xmlns:html='http://www.w3.org/TR/REC-html40'>
> >    <target name="t">
> >        <echo html:class="reallyimportant">message</echo>
> >     </target>
> > </project>
> >
> > 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
> attributes.
>
> >> 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
> >> antlibs.
> >
> > This is true, but using namespaces one could do:
> > <project  xmlns:html='http://www.w3.org/TR/REC-html40'>
> >    <html:target name="t">
> >        <echo>hello world</echo>
> >     </html:target>
> > </project>
> >
> > 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 :-)

Is True...

>
> 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.

My idea is to get PH2 to ignore name spaces it does not understand - they
then will not form part of the tree.

>
> >> > 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.
> >
> > <addon:copypath>
> >     <path refid="x"/>
> >     <remoteurl url="http://" retry="no"/>
> > </addon:copypath>
> >
> > is different from:
> >
> > <addon:copypath>
> >     <addon:path refid="x"/>
> >     <addon:remoteurl url="http://" retry="no"/>
> > </addon:copypath>
>
> 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 ?

I propose using the first case.

>
> >> 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
> >> >     <element type="newtype"/> will need to be made ns-aware. either
> >> >     <newtype for-element="element"/> 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 (
> >> <element type="antcontrib:if" /> ), 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.

I propose using the <element [type attribute name]="antconrib:if"/> form,
 where
[type attribute name] is "typedef" or "ant-type"  or maybe "element-type".

"type" cannot be used as it is used by current tasks / datatypes.

Peter.

Mime
View raw message