> -----Original Message-----
> From: Henri Yandell [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, 20 July 2006 10:04 AM
> To: Ant Developers List
> Subject: Re: Abusing the BuildListener
> 
> On 7/12/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > I suspect this isn't what was intended for the build listener, but 
> > I've been using it to override the build.xml for <junit> tasks. In 
> > startTask I ensure that haltonerror and haltonfailure are set to 
> > false. Next up I want to ensure there is always a <formatter 
> > type="xml"/>, but adding a new task in seems a lot more 
> painful than 
> > simply modifying the existing objects.
> 
> Very happy; I've got it working. Many thanks for all the help!
> 
> I kept playing with the direction Matt had me go and it 
> suddenly worked (when I was really looking to see what the 
> old error was). The following code forces the haltonfailure 
> and haltonerror attributes to always be false; and ensures 
> that an xml output is always done.
> 
>       public void taskStarted(BuildEvent event) {
>             if(event.getTask().getTaskName().equals("junit")) {
>                 UnknownElement ue = (UnknownElement) event.getTask();
>                 RuntimeConfigurable rc = ue.getWrapper();
>                 rc.setAttribute("haltonfailure", "false");
>                 rc.setAttribute("haltonerror", "false");
> 
>                 UnknownElement ue2 = new UnknownElement("formatter");
>                 ue.addChild(ue2);
> 
>                 FormatterElement fe = new FormatterElement();
>                 RuntimeConfigurable rc2 = new 
> RuntimeConfigurable(fe, "formatter");
>                 rc2.setAttribute("type", "xml");
>                 rc.addChild(rc2);
>             }
>     }
> 
> 
> Hopefully there won't be any surprises when I throw this into 
> a real scenario.

Something to keep in mind regarding the above ... the impact of setting
"haltonfailure" and "haltonerror" values to false basically results in the
full execution of the all test - however - my experience is that you will
need to add an error and failure property and test these properties after
the build for non-null conditions (which should be used to force build
failure), otherwise you end up with a situation in which testcase failures
occur but the build reports success.

It would probably be a good idea just to check you scenario with a testcase
setup to fail (which should trigger a build failure) just to make sure that
things are working as you expect.

Cheers, Steve.


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

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

Reply via email to