DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29797>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29797 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW ------- Additional Comments From [EMAIL PROTECTED] 2005-05-27 00:25 ------- 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. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
