ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: TaskContainer and nested data-types
Date Fri, 08 Nov 2002 19:22:54 GMT
What I tried to do in embed ( and seems to work - at least for gump test ) 
is move as much logic as possible out of ProjectHelper.

I think making things consistent would help a lot - and IMO that 
means creating UnknownElement for all elements, including those on top

I would also vote to remove the restriction on 'only tasks inside 
TaskContainer' - even if it may be counterintuitive as name. I think
the right direction is to treat task and data types the same. We 
already did that for the top level.

If a TaskContainer ever wants to execute a non-task - it'll get
an exception or it'll be a no-op.


Stefan Bodewig wrote:

> Hi,
> a technical question, for a change 8-)
> If you look into ProjectHelperImpl, you'll see
>         public void startElement(String name, AttributeList attrs) throws
>         SAXParseException {
>             if (task instanceof TaskContainer) {
>                 // task can contain other tasks - no other nested elements
>                 possible new TaskHandler(helperImpl, this, (TaskContainer)
>                 task,
>                     wrapper, target).init(name, attrs);
> the intention seems to be that TaskContainers are not allowed to hold
> data-types.  Now try this build file snippet
>     <sequential>
>       <path id="path">
>         <pathelement location="loc1" />
>       </path>
>     </sequential>
> it will work.  The reason is that ProjectHelperImpl inserts a
> UnknownElement for <path> and this one replaces itself with the
> data-type at runtime.
> If you now replace <sequential> with a TaskContainer of your own,
> things start to get messy.
>     <mycontainer>
>       <path id="path">
>         <pathelement location="loc1" />
>       </path>
>     </mycontainer>
> will not work in CVS HEAD at all - because <mycontainer> will become
> an UnknownElement itself and the handleChildren code in there doesn't
> allow any non-tasks to slip through.
> To make things worse, in 1.5.1 it will depend on where you place the
> <taskdef> for mycontainer.  If you put it at the top-level in front of
> the target containing the snippet above, it will work.  If you place
> the taskdef after the target (or inside a target), it will fail.
> Before I go and make things consistent, I thought I'd ask you what the
> correct behavior would be 8-)
> Is 1.5.1 wrong in that it should never allow the construct above to
> pass?  If so, the sequential case must not pass either.  Be aware that
> changing this may cause some build files to break.
> Should data-types be allowed inside TaskContainer?  If so,
> UnknownElement needs to get fixed.
> Stefan

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message