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: antlibs/namespaces
Date Thu, 06 Nov 2003 11:54:47 GMT
On Thursday 06 November 2003 10:02, Stefan Bodewig wrote:
> On Wed, 5 Nov 2003, peter reilly <peter.reilly@corvil.com> wrote:
> > On Wednesday 05 November 2003 16:26, Dominique Devienne wrote:
> >> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> >> >
> >> > On Wed, 5 Nov 2003, Matt Benson <gudnabrsam@yahoo.com> wrote:
> >> > > In beta1, the following worked:
> >> > >
> >> > > <myns:mytask>
> >> > >   <myns:mytype />
> >> > > </myns:mytask>
> >> > >
> >> > > In beta2, I get an error to the effect that "mytask"
> >> > > does not support nested "mytype".
> >
> > There was a bug in beta1 with regard to namespace
> > handling of nested elements (the prefix was
> > incorrectly ignored).
> >
> > This has been fixed in beta2.
>
> See Matt, I told you it wasn't decided yet.  Obviously Peter and I
> disagree on what the "correct" behavior would be 8-)

The bug that was fixed was the prefix being ignored (html:mytype would
also work).
The bug meant that add(type) did not work for namespaced types.

I noticed it while testing Dale's new conditions-
<antcontrib:if>
  <antcontrib:ispropertytrue property="a"/>
  <then>
    <echo>a is true</echo>
  </then>
</antcontrib:if>
         
>
> > The current behaviour is that introspection discovered
> > nested elements belong to the ant default namespace.
>
> Why do you think it should do so?

Well, I originally thought that the namespace could be
used to distinguish between types and tasks defined by
third parties.

There is no need to use namespace to distinguish the nested
elements (except for typedef'ed elements), so they would
be in the ant default namespace.

However, I understand the problem of writing schemas, using xml editors and 
also the fact that it is a little strange ...

So now I think that the nested elements should have the
namespace of the enclosing element (except for typedef'ed elements)

I have a patch ready to do this (enclosed) (without unit tests)
and am ready to commit.

Note that this applies also to types/tasks created by <presetdef/>.

<antgoodies:javac>
   <antgoodies:exclude name="**/Ignore*.java"/>
</antgoodies:javac>

Also note that this will affect all current users of namespaced antlib's.
So when a new beta is released, this needs to be included in the
release notes.

>
> >> And what about an Ant task (say <dummy>) with a AddXyz(Xyz xyz)
> >> method, and I have an <my:xyz> in my AntLib that extends Xyz?
> >> Should I be able to say:
> >>
> >> <dummy>
> >>   <my:xyz ... />
> >> </dummy>
> >
> > No, the ant task needs to have a add(Xyz xyz) method for this to
> > work ...
>
> Peter is correct (of course, I should add).
>
> > well there is an undocumented attribute ant-type
>
> we really should document it.
Yes...

Note that when this feature was first disussed it was pointed out that
ant-type does not work for Type create<NestedElement>() methods - like
<src/> in javac.

It was assumed that one could add new methods - add<NestedElement>(Type..)
to get around this problem, and make add<NestedElement> have a lower
priorirty than create<NestedElement>().

This however does have the nasty effect of causing problems for new classes
that extend for example javac and override the createSrc() method.
The introspection will still pick up the addSrc() method.
Peter

Mime
View raw message