You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Mike Castle <da...@ix.netcom.com> on 2003/01/13 18:25:03 UTC
detecting build failures with OUT exiting
I'm knew to ANT and still in the process of trying to get up to speed on
everything, including still reading through _Java Development With Ant_.
I have come into a job with an existing build infrastructure. Normal
builds are all ant, but the automated build stuff is a combination of shell
scripts and ant. I am trying to migrate all of the functions that shell
script provides into the build file for a couple of reasons. First,
practice. Second, being able to easily migrate build system back and forth
between our Linux and Win32 boxes (this builds will eventually incorporate
running the test suite automatically, and I'll probably bounce back and
forth between environments until I get stuff in place to run them both).
The project currently has the following layout:
/lib1/.../build.xml
/lib2/.../build.xml
...
/libN/.../build.xml
/project/.../build.xml
/pseudoprojectbuilddriver/.../build.xml
Now, all of the libraries are intended to be maintained independently for
possible use in other applications, but currently nothing else uses them.
Additionally, as the main project needs new features added, new features
must be added to various libraries in parallel. So, while it annoys the
hell out of me, no one else is interested in turning all of the libraries
into individually released components.
At least the main project build file doesn't directly interface with all of
the library xml files. Instead we have a pseudo project that calls each of
the other build files with <antfile/> in the appropriate order.
Now, the problem with <antfile/>, at least as far as I have been able to
read in the docs and ant-user archives, is that there is no
failonerror="no" equivalent. Nor do I see a general way to catch failures.
So, if a file fails to compile, the automated build exits, and I can't send
off an email from inside ant to the appropriate individuals telling them
they need to buy the next round.
So, is changing <antfile/> to <exec ant/> my only option? For automated
builds, we have some logger stuff set up to save all of the output, but
that doesn't happen for regular builds. So that may be a little tricky
(then again, it may all ``just work'', haven't yet looked at anything down
that route yet).
Or I may just invoke myself with exec with the standard build target, and
not have to worry about changing all of the <antfile/> tasks.
What would my other options be? What sort of gotchas are there to look for
in replacing <antfile/> with <exec ant/>? Are there any very near term
plans for offering up failonerror type of handling for <antfile/>? I'd
seen some references for plans, mostly related to ant2, but there's so much
noise showing up when I do searches that it might be getting lost.
Any comments, ideas, useful search terms appreciated.
mrc
--
Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: detecting build failures with OUT exiting
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Mike Castle" <da...@ix.netcom.com>
To: "Ant Users List" <an...@jakarta.apache.org>
Sent: Monday, January 13, 2003 15:13
Subject: Re: detecting build failures with OUT exiting
> > There are <try> and <catch> tasks in ant-contrib.sf.net; these let you
wrap
> > the <ant> calls. Covered on p256 of the book, btw.
>
> Ack! Information overload. And on such a memorable page number too!
>
> But this definitely looks like what I was looking for. Thanks!
>
> I take it that this is a different implementation of the same idea posted
> by Dale Anson elsewhere in this thread?
not if he used <try> and <catch>
>
> > > So, if a file fails to compile, the automated build exits, and I can't
> > send
> > > off an email from inside ant to the appropriate individuals telling
them
> > > they need to buy the next round.
> >
> > MailLogger is the way to do this. I like your 'your broke the build'
> > punishment policy.
>
> The current script uses the XmlLogger and saves that off. If there is
> an error it sends an email saying "go here." I'll probably keep that
> method and use the <mail> task. They get annoyed if I even hint at
> changing stuff to drastically, so I don't want to change what they
receive.
ok, but the purpose of the mail logger is to send out success/failure
emails, which is really what you want to do.
> Considering the number of emails we've sent out today, someone may have to
> just bring in a pony keg later this week....
Wait till you add <checkstyle> to the build...
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: detecting build failures with OUT exiting
Posted by Mike Castle <da...@ix.netcom.com>.
On Mon, Jan 13, 2003 at 12:19:06PM -0800, Steve Loughran wrote:
> From: "Mike Castle" <da...@ix.netcom.com>
> > I'm knew to ANT and still in the process of trying to get up to speed on
> > everything, including still reading through _Java Development With Ant_.
>
> but of course :)
I was wondering which one of you two would respond first. :->
> > Now, the problem with <antfile/>, at least as far as I have been able to
> > read in the docs and ant-user archives, is that there is no
> > failonerror="no" equivalent. Nor do I see a general way to catch
> failures.
>
>
> There are <try> and <catch> tasks in ant-contrib.sf.net; these let you wrap
> the <ant> calls. Covered on p256 of the book, btw.
Ack! Information overload. And on such a memorable page number too!
But this definitely looks like what I was looking for. Thanks!
I take it that this is a different implementation of the same idea posted
by Dale Anson elsewhere in this thread?
> > So, if a file fails to compile, the automated build exits, and I can't
> send
> > off an email from inside ant to the appropriate individuals telling them
> > they need to buy the next round.
>
> MailLogger is the way to do this. I like your 'your broke the build'
> punishment policy.
The current script uses the XmlLogger and saves that off. If there is
an error it sends an email saying "go here." I'll probably keep that
method and use the <mail> task. They get annoyed if I even hint at
changing stuff to drastically, so I don't want to change what they receive.
Considering the number of emails we've sent out today, someone may have to
just bring in a pony keg later this week....
Cheers,
mrc
--
Mike Castle dalgoda@ix.netcom.com www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: detecting build failures with OUT exiting
Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Mike Castle" <da...@ix.netcom.com>
To: <an...@jakarta.apache.org>
Sent: Monday, January 13, 2003 09:25
Subject: detecting build failures with OUT exiting
>
> I'm knew to ANT and still in the process of trying to get up to speed on
> everything, including still reading through _Java Development With Ant_.
but of course :)
> Now, the problem with <antfile/>, at least as far as I have been able to
> read in the docs and ant-user archives, is that there is no
> failonerror="no" equivalent. Nor do I see a general way to catch
failures.
There are <try> and <catch> tasks in ant-contrib.sf.net; these let you wrap
the <ant> calls. Covered on p256 of the book, btw.
> So, if a file fails to compile, the automated build exits, and I can't
send
> off an email from inside ant to the appropriate individuals telling them
> they need to buy the next round.
MailLogger is the way to do this. I like your 'your broke the build'
punishment policy.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: detecting build failures with OUT exiting
Posted by Dale Anson <da...@germane-software.com>.
Hi Mike,
I sent the following in response to another question this morning, looks
like it answers your question as well.
Dale Anson
danson@germane-software.com
-------------------
Hi Roman,
I've written a try/catch/finally task that I'm in the process of getting
ready for submitting to the ant-dev group for consideration. You can
download it at
http://prdownloads.sourceforge.net/antelope/Antelope_tasks_2.17.zip?download
This zip contains some other tasks that you may or may not want. Docs
are included in the zip.
Basically, you use the task like this:
<target name=...>
<try>
<!-- put your tasks here -->
<catch>
<!-- do failure handling tasks here -->
</catch>
<finally>
<!-- like java, this is optional -->
</finally>
</try>
</target>
Dale Anson
danson@germane-software.com
Roman Rytov wrote:
> In my script I access VSS and at the beginning check out some files. At
> the end of the script I check them in back. I want to catch all failure
> situations and to make logical action (check those files in in my case).
> Is there a way to apply a kind of FINALLY in Ant?
>
> Roman Rytov
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
Mike Castle wrote:
>I'm knew to ANT and still in the process of trying to get up to speed on
>everything, including still reading through _Java Development With Ant_.
>
>I have come into a job with an existing build infrastructure. Normal
>builds are all ant, but the automated build stuff is a combination of shell
>scripts and ant. I am trying to migrate all of the functions that shell
>script provides into the build file for a couple of reasons. First,
>practice. Second, being able to easily migrate build system back and forth
>between our Linux and Win32 boxes (this builds will eventually incorporate
>running the test suite automatically, and I'll probably bounce back and
>forth between environments until I get stuff in place to run them both).
>
>The project currently has the following layout:
>
>/lib1/.../build.xml
>/lib2/.../build.xml
>...
>/libN/.../build.xml
>/project/.../build.xml
>/pseudoprojectbuilddriver/.../build.xml
>
>Now, all of the libraries are intended to be maintained independently for
>possible use in other applications, but currently nothing else uses them.
>Additionally, as the main project needs new features added, new features
>must be added to various libraries in parallel. So, while it annoys the
>hell out of me, no one else is interested in turning all of the libraries
>into individually released components.
>
>At least the main project build file doesn't directly interface with all of
>the library xml files. Instead we have a pseudo project that calls each of
>the other build files with <antfile/> in the appropriate order.
>
>Now, the problem with <antfile/>, at least as far as I have been able to
>read in the docs and ant-user archives, is that there is no
>failonerror="no" equivalent. Nor do I see a general way to catch failures.
>So, if a file fails to compile, the automated build exits, and I can't send
>off an email from inside ant to the appropriate individuals telling them
>they need to buy the next round.
>
>So, is changing <antfile/> to <exec ant/> my only option? For automated
>builds, we have some logger stuff set up to save all of the output, but
>that doesn't happen for regular builds. So that may be a little tricky
>(then again, it may all ``just work'', haven't yet looked at anything down
>that route yet).
>
>Or I may just invoke myself with exec with the standard build target, and
>not have to worry about changing all of the <antfile/> tasks.
>
>What would my other options be? What sort of gotchas are there to look for
>in replacing <antfile/> with <exec ant/>? Are there any very near term
>plans for offering up failonerror type of handling for <antfile/>? I'd
>seen some references for plans, mostly related to ant2, but there's so much
>noise showing up when I do searches that it might be getting lost.
>
>Any comments, ideas, useful search terms appreciated.
>
>mrc
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>