ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blackard, Robert" <>
Subject RE: Build and Confiuration Managment with Ant... a.k.a. running A nt _ from_ JSP/Servlet
Date Thu, 16 Aug 2001 15:12:51 GMT
An AWT application, by definition, provides a GUI and should never be called
by another java program.

ANT it a TOOL... that's why it has tool in the package name... tools get
called by other tools...

That said...

This is a philosophical issue that we won't solve and that I concede I'll
never change anyone's mind about - and I guarantee you'll never change my
mind on this issue.  It's my own fault for raising such an issue.  I've been
in the industry for 20 years, and used Java on and off since the "Hooked on
Java" book first came out.  I should know better than to start such debates
in a news group.  I apologize to everyone for my failure to use a little
common sense.

> -----Original Message-----
> From: Conor MacNeill []
> Sent: Thursday, August 16, 2001 9:55 AM
> To:
> Subject: Re: Build and Confiuration Managment with Ant... 
> a.k.a. running
> Ant _ from_ JSP/Servlet
> Robert,
> > Now, I'm getting out my soap box, so feel free to ignore 
> the rest of this
> > message.
> >
> > As I understand it, one of the fundamental reasons that the 
> main() method
> > was defined as void was that not all operating systems 
> supported result
> > codes.  What Ant, and any other system that uses a System.exit() is
> doing,
> > is intentionally violating the defined language.
> huh? Have you ever run a AWT app? How do you terminate the AWT Event
> thread? GUIs generally have to resort to System.exit to 
> prevent the whole
> thing hanging.
> >
> > Further, using a System.exit() anywhere assumes that the currently
> executing
> > code is the only code running in the current JVM.  This 
> should be very
> well
> > documented in any Installation and Usage documentation, but 
> also violates
> > the ability of a single JVM to be used to manage multiple executing
> > applications.
> The Main class is generally intended to launch Ant from a command line
> environment, hence all the option processing etc. This is not 
> really the
> way you should go about embedding Ant in another application. 
> Think of Main
> as the command line front end to Ant. Think of the Project 
> object as your
> main Ant API.
> >
> > That said, the standard argument for using a System.exit() 
> is that it
> > support the use of scripting with tools like a Unix shell or Perl.
> > Certainly, providing an exit code is a means to support 
> this, but again,
> not
> > all operating systems support exit codes.
> Indeed, this is why Main uses System.exit();
> >
> > In this mail, and another posting that I finally uncovered
> > 
5.html, you
> describe using the Security Manager to trap such behavior.

I'd say this is not to stop Ant calling System.exit(), but to protect Ant
from other code that calls System.exit() :-)

> IMHO I beleive
> that it sould be the person that expects exit codes, and is therefore
> seeking behavior different that that defined by the language, that should
> required to customize their environment by using a facility to generate
> codes, for example, creating a Runner class that catches exceptions and
> returns exit codes and executing through
> the Runner class.

That is what Main is - the command-line front-end to Ant.

There are other things that Main will do that would be considered "anti
social" in a shared VM environment, including controlling System.out and

So, in theory you should build a front end, say AntJSPFrontEnd or whatever,
and use it to configure the Project object. Before you do, I will warn you
though, that there will be some problems. The Project object does not
expose all methods as public. Additionally, some processing should probably
be moved from Main to Project to save it being duplicated, etc. It is not
perfect but this approach has been used to integrate Ant with NetBeans.


View raw message