From: "Sam Ruby" <[EMAIL PROTECTED]>

> Stefan Bodewig wrote:
> >
> > I think I know what's going on, but I don't have all pieces together
> > to test it (yet) - does it work if you move the <taskdef> for FOP's
> > manifest task out of the target and make it a sibling of target?
> 
> Yes.
> 
> If I move the taskdefs to the top of the build.xml, I get one message:
> 
>    Trying to override old definition of task manifest
> 
> Then everything proceeds fine - apparently the xml-fop version of the task
> is used.

A very interesting problem. I guess this is happenning because ANT is resolving 
the
element to the task instance before finding and acting on the <taskdef/> from 
the
user. Which escentially means that *everytime we add a new task to ANT* we are
actually breaking backward compatibility. OH MY GAAAAAD ! 8-o

For every task we add, there may be some buildfile somewhere that may be broken!

Does this mean we should stop adding features to ANT because the BCS is 
paramount?

Actually a solution to this problem would be to change ProjectHelper to always 
defer
instantiation (i.e., use UnknownElement) and wait until execution to resolve 
using
any new definitions.

But if we really do this seriously, then we shouldn't by assumming that certain 
names
are special (can be at children of project) since those names can be used to 
mean
something else. ;-)

Oh well,

Jose Alberto



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to