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.
hmmm. 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?
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 - http://www.manning-sandbox.com/thread.jspa?threadID=7567&tstart=45 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: http://debic.net/backstage/SuSE_gifs/ Thank you for considering this request. Boris Debic. Foster City, CA.
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.
Depending on your environment you may be able to trap the System.exit call. Check out SecurityManager.checkExit
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).
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.
Jesse, would you (and perhaps Darin) be able to draft up what a smart/easy/versatile point-of-entry should look like?
*** Bug 34312 has been marked as a duplicate of this bug. ***
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 classes. 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 :-)
Perhaps. The quickest answer I can give offhand is http://www.netbeans.org/source/browse/~checkout~/ant/src/org/apache/tools/ant/module/bridge/BridgeInterface.java but there is a lot more to it than that (e.g. input handlers).