Just to give a historic perspective, there have been attempts to solve this issue in the past. The one I remember just defined an Adapter task that contained the datatype within the container (including targets and top level) very simple solution.
It never made it in. The main issue I think was the <script/> tasks which relies too much on the internal representation of things. I think you can find the Adapter code on one of the old proposals. Jose Alberto > -----Original Message----- > From: Costin Manolache [mailto:[EMAIL PROTECTED] > Sent: 08 November 2002 19:23 > To: [EMAIL PROTECTED] > Subject: Re: TaskContainer and nested data-types > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
