Kenneth Burgener | 19 Oct 23:20

Failed taskdef reporting as successful build

Hello.

I using "Anthill version 1.8.1.303" and I have a taskdef class that
cannot be found, because I deleted it.  What concerns me is the build
machine is reporting the build as a successful build, but the ant logs
clearly state the build failed.

Here is the taskdef:

  <taskdef name="zkm" classname="ZKMTask"/>

I have tried adding onerror="failall", with no difference.  If ant is
reporting "BUILD FAILED" how would that cause Anthill to assume this was
a successful build?

Subject: TestAnthill 1.3 build succeeded
-------------------------------------
c:\anthill\publishDir\TestAnthill\buildLogs\TestAnthill-1.3-build.log
BUILD FAILED
c:\Build\TestAnthill\build.xml:5: taskdef class ZKMTask cannot be found

Total time: 0 seconds

Thanks,
Kenneth
Eric Minick | 20 Oct 18:26

Re: Failed taskdef reporting as successful build

Ken,

This is the famed "Ant on Windows is broken" error. On Windows, a 
default install of Ant will always return an exit code reporting 
success. You can modify the ant.bat file to ensure it does return an 
exit code to correct this problem. There's an example ant.bat with this 
modification made that ships with Anthill. The rumor is that Ant 1.6 
also has a fix, but we've seen mixed results from people using it.

This is also discussed at some length on Ant's issue tracker:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13655

Regards,

Eric

Kenneth Burgener wrote:
> Hello.
>
> I using "Anthill version 1.8.1.303" and I have a taskdef class that
> cannot be found, because I deleted it.  What concerns me is the build
> machine is reporting the build as a successful build, but the ant logs
> clearly state the build failed.
>
> Here is the taskdef:
>
>   <taskdef name="zkm" classname="ZKMTask"/>
>
> I have tried adding onerror="failall", with no difference.  If ant is
> reporting "BUILD FAILED" how would that cause Anthill to assume this was
(Continue reading)

Eric Minick | 22 Oct 18:00

Re: Failed taskdef reporting as successful build

Ken,

This is the famed "Ant on Windows is broken" error. On Windows, a 
default install of Ant will always return an exit code reporting 
success. You can modify the ant.bat file to ensure it does return an 
exit code to correct this problem. There's an example ant.bat with this 
modification made that ships with Anthill. The rumor is that Ant 1.6 
also has a fix, but we've seen mixed results from people using it.

This is also discussed at some length on Ant's issue tracker:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13655

Regards,

Eric

Kenneth Burgener wrote:
> Hello.
>
> I using "Anthill version 1.8.1.303" and I have a taskdef class that
> cannot be found, because I deleted it.  What concerns me is the build
> machine is reporting the build as a successful build, but the ant logs
> clearly state the build failed.
>
> Here is the taskdef:
>
>   <taskdef name="zkm" classname="ZKMTask"/>
>
> I have tried adding onerror="failall", with no difference.  If ant is
> reporting "BUILD FAILED" how would that cause Anthill to assume this was
(Continue reading)

Kenneth Burgener | 24 Oct 16:51

Re: Failed taskdef reporting as successful build

Eric,

Awesome, thank you for the reply.  I had assumed it was a problem with
Anthill, so I was looking in the wrong spot.  I was fortunate enough
that this and a few other minor issues surrounding our build machine was
enough to convince a conversion to a Linux build machine.   :-)  hoorah!

Kenneth

Eric Minick wrote:
> Ken,
>
> This is the famed "Ant on Windows is broken" error. On Windows, a
> default install of Ant will always return an exit code reporting
> success. You can modify the ant.bat file to ensure it does return an
> exit code to correct this problem. There's an example ant.bat with
> this modification made that ships with Anthill. The rumor is that Ant
> 1.6 also has a fix, but we've seen mixed results from people using it.
>
> This is also discussed at some length on Ant's issue tracker:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=13655
>
> Regards,
>
> Eric

Gmane