ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blackard, Robert" <robert.black...@tgslc.org>
Subject RE: Build and Confiuration Managment with Ant... a.k.a. running A nt _ from_ JSP/Servlet
Date Thu, 16 Aug 2001 15:44:59 GMT
Well, I take part of this back...

In my haste, I missed the very clear statement in the Javadoc for
org.apache.tools.ant.Main:

"If you integrating Ant into some other tool, this is not the class to use
as an entry point. Please see the source code of this class to see how it
manipulates the Ant project classes."

Again, my own fault.  I improperly assumed that Main was the catch-all entry
point to the Ant tool.

For everyone's reference, the correct procedure is to write a class to act
as the entry point.  This class must create an org.apache.tools.ant.Project
object and configure it - which includes adding build listeners, using a
ProjectHelper to read the xml file, and defining properties - trigger the
build started event, initiale the project, and callexecuteTargets(), and
trigger the build finished event.

Just because I would never write an entry point this way doesn't mean that
other people can't choose to do so.

> -----Original Message-----
> From: Blackard, Robert [mailto:robert.blackard@tgslc.org]
> Sent: Thursday, August 16, 2001 10:13 AM
> To: 'ant-user@jakarta.apache.org'
> Subject: RE: Build and Confiuration Managment with Ant... 
> a.k.a. running
> A nt _ from_ JSP/Servlet
> 
> 
> 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 [mailto:conor@cortexebusiness.com.au]
> > Sent: Thursday, August 16, 2001 9:55 AM
> > To: ant-user@jakarta.apache.org
> > 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
> > > 
> > http://www.mail-archive.com/ant-dev@jakarta.apache.org/msg0797
> 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
> be
> > required to customize their environment by using a facility 
> to generate
> exit
> > codes, for example, creating a Runner class that catches 
> exceptions and
> > returns exit codes and executing 
> org.apache.tools.ant.Main.main() 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
> System.err.
> 
> 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.
> 
> Conor
> 
> 
> 

Mime
View raw message