Additionally Ant can be used to shell command lines with the "exec" command. I've tried building with nmake from visual studio 6.0, but I don't think Ant converts the quotes properly that are required for specifying the build configuration.
e.g. <exec dir="src/win32/someproject/" command="nmake /f "someproject.mak" cfg="someproject - Win32 Release"" os="windows" output="someprojectbld.txt"/> Jayme -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 11, 2000 1:17 PM To: [EMAIL PROTECTED] Subject: How to convince our IT manager to allow ANT? I've been testing out Ant for doing our java builds instead of make, and I'm convinced that it's a superior tool. I was able to easily do things that would have taken me a lot longer to write in make syntax and the build.xml files are much simpler to read and maintain. Yesterday, myself and one of our system architects tried to convince our IT manager to officially allow ANT for building java programs, and met with little success. The arguments were: 1. Him: Ant doesn't do anything that make can't do. Me: Because make can call any shell command, there's really nothing make can't do if you work at it hard enough. My point is that Ant does things more elegantly. 2. Him: Since Ant would only be used for java builds, we'd need to support 2 tools, Ant for java and make for C++. Therefore, higher support costs. Me: Ant is simpler than make, so it will not have as many problems requiring a build expert as make will. Also, it can be optional for java, so not every developer needs to be trained to know Ant. 3. Him: I thought javac already automatically detected dependencies and compiled all the necessary files, which means your makefile would generally be trivial and not require a sophisticated tool. Me: First, I've heard of problems with javac with big directories of files being compiled. Second, I don't think javac can autocompile needed classes which are in different packages (which we use extensively). 4. Him: Make is standard, Ant is not, and may never become a widely used too. Me: I expect some sort of XML based tool to become a widely used replacement for make, although you can't predict whether Ant will or won't. Besides, it provides value in the short run and increases developer productivity. Finally, so what if it's not a standard? As long as it's useful to us, it doesn't matter if other companies are all using it. So, the question is: "How do I convince a reluctant manager to see the value of Ant?" I am planning to research javac's automatic compiling ability, but I don't put much faith in it. I just didn't have hard proof at the meeting to show. I can't quantify support costs, so I guess I'm going to have to rely on showing him how it can increase productivity. We're going to try to convince the head of configuration management probably tomorrow, and then go back to our manager if he will join our side. Any suggestions?
