Bug 29797

Summary: Calling Ant from other Java Applications
Product: Ant Reporter: Boris Debic <debic>
Component: CoreAssignee: Ant Notifications List <notifications>
Status: NEW ---    
Severity: enhancement CC: Darin_Swanson, debic, jglick, olazzizzera
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: other   

Description Boris Debic 2004-06-25 04:25:09 UTC
This is an enhancment request that should help folks who use Ant from their own
Java applications. My example is simple: I have written a build java application
that uses Ant to drive the build portion of the build but uses java servlets to
drive other important build related processes that are important for my users. 

In all previous versions of Ant, including Ant 1.5.x we copied the Main.java
class into an AntMain.java replaced system.exit(0)'s with returns and called
this class from our application. It works perfectly for us. We get to see all
the exceptions etc. 

So my enhancement request here is to formalize a way to call java from other
java apps (asumming that anything passed by the command line can be passed as
well) and make this an integral part of future releases. It means a lot to
developers like myself who like the tight integration this method provides,
especially the possibility to handle any exceptions that could possibly occur
while running Ant build files.

Please feel free to contact me for any additional details at the cc email
provided with the req.
Comment 1 Steve Loughran 2005-03-31 23:51:50 UTC

Ant is fairly well designed to be used from other apps, because even though Main
calls system.Exit(), it is the only place that does so. instead it provides a
detailed and stable API For low level project, task manipulation. 

Have a look at the "Using tasks outside of Ant" bit of the manual, to see these.

Is the API that is introduced there not sufficient?
Comment 2 Boris Debic 2005-05-27 00:25:51 UTC
Yes, the API is insufficient. Ant main should not do a System.exit(). I
understand that nowdays it is not recommended to embed Ant into other
applications by doing a call to Ant main directly because of unexpected behavior
that may result if one does so. See -

However let me argue for a design change then.

Ant is a great piece of software that does an exceptionally good job as a build
tool and make replacement. That being said, the world of software development is
much more complex these days and folks who run production builds at some of the
top software comapnies need more than just a build tool. The solution is usually
one of the two, wrtite your own build system app or use a third party system,
something like AntHill or Luntbuild. Such an application usually integrates
several important build cycle aspects.

Now the reason I selected Ant several years ago is that I knew I will need to
write such an app beyond Ant (that drives and schedules builds on sveeral
different OS's at the same time, collects and manages the log files and
binaries, does resource house keeping, serializes important results into a
databse and so forth) - the reason was that I wanted to finally move beyone the
so 'make' world of spawning things and getting exit codes to try to figure out
what went wrong. I created a new class in ant replaced system.exits() with
returns and voila I had a sleek way to do builds and see any problems IN DEPTH
becuase I could see and handle the exceptions.

I still do this in Ant 1.6.2. but it became a little more involved from the
simple change in Ant 1.2. This is why I ask for future development on Ant to
provide a supported and documented venue (an API perhaps) on how to run Ant from
a calling java application. I am not interested in running some tasks and I will
explain why. 

When I work with developers our philosophy is if you ant build runs from the
command line it will run from the buidl system as well because this is exactly
what we do. Run the build.xml within the build system the same way ant would do
from the command line. This is extremely important when you pitch sophisticated
build system s to developers. And it's good practice too because you want to
have a safe fall back in case something goes wrong with the build system.
Forcing the app to deal with a separate API practically means that you need to
maintain 2 different sets of build files this in the end amounts to problems.

On the other hand you will argue, well just call Ant from your app as an
executable i.e. spawn it. While this is obviously possible, it is a far more
inferior solution for someone who uses java for his application as he loses the
fine control and debuging venue that is given to him with a java method call. 

I am sure I am not the only one who deoes something like this with Ant, but taht
being said I am sure there's not a bnig number of us out there either. However,
having sauch an entry point to Ant will only work for it's benefit. it's not
like we are trying to steal Ant by plugging it into our apps, I don't mind Ant
banners or if you want to put them into logs and output. But I think it's better
that you guys maintain a System.exit()less entry point for those of use who want
to use Ant this way rather then us 'fixing' Ant every time a new release comes out.

For some screen shots of the build App visit:

Thank you for considering this request.
Boris Debic.
Foster City, CA.
Comment 3 Matt Benson 2005-05-27 00:36:47 UTC
Why do you have to "fix" Ant every time a new release comes out?  If you
instantiate a Project, configure it via ProjectHelper and a File object, and
execute the targets you want, that's basically all you have to do.  In other
words, you can clone what you need from oata.Main, package that as your own
entry point to Ant, and it should simply work against new binary Ant distributions.
Comment 4 Jeffrey E. Care 2005-05-27 00:55:47 UTC
Depending on your environment you may be able to trap the System.exit call.

Check out SecurityManager.checkExit
Comment 5 Jesse Glick 2005-05-27 02:33:08 UTC
Generally I have found embedding Ant to be feasible but not as simple as it
probably could be. There are a number of subtleties you need to figure out. And
you cannot use an embedded Ant for certain kinds of unforked <java> if you
already have a security manager (bug #34229).
Comment 6 Boris Debic 2005-05-27 03:01:18 UTC
I hear the point of comments #3 and #4 but that's exactly what I am pointing at.
Today there's no notion that Ant may be emmbedded and as such things can change
in future releases. I am not contesting whether the solution already exists
today, so it maybe only a documentation point (i.e. How to embed Ant into a Java
App). What I am trying to say this use case should be recognized, formalized and
supported, this way if things are redesigned in the future the maintainers will
be aware of this use case. 

Also whichever method of support is chosen it should work the same way as if
running ant against a build xml file from the command line, so the files used
for the embedded app and developer side testing on standalone Ant are the same.
Comment 7 Matt Benson 2005-05-27 15:34:53 UTC
Jesse, would you (and perhaps Darin) be able to draft up what a
smart/easy/versatile point-of-entry should look like?
Comment 8 Matt Benson 2005-05-28 00:28:46 UTC
*** Bug 34312 has been marked as a duplicate of this bug. ***
Comment 9 Darin Swanson 2005-05-28 01:33:16 UTC
Of course the Eclipse Ant entry point(s) are available for all to see via the 
source of the Ant Core and Ant UI plugins of Eclipse. See the InternalAntRunner 

That said...we could argue smart and versatile...I would vote against easy :-)

One of my problems is that I have to maintain entry points that can work 
against "any" Ant (where any is defined as all Ants released since Eclipse 
1.0...this is my real pain point) and yet still expose the new functionality in 
the latest Ant release. 
As well there is the multi levels of configuration from those pesky GUI 
elements :-)
Comment 10 Jesse Glick 2005-05-28 18:00:00 UTC
Perhaps. The quickest answer I can give offhand is


but there is a lot more to it than that (e.g. input handlers).