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
level.
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.
Costin
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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
