Here is the offending page from Brent's book. I think it will be on the MSDN web site before long, as it is the chapter promised this month -
http://msdn.microsoft.com/Longhorn/understanding/books/rector/default.aspx
I have added my commentary. This is the last paragraph on chapter 2, just after a critique of make. My comments are in brackets.
MSBuild vs Ant ===============
A similar frequently asked question is why develop a new XML-based build system when there's an existing system called Ant? Ant is a Java, open source build system from Apache.org that uses XML-based configuration files. There's a .NET port called Nant from nant.sourceforge.net as well. On the surface, MSBuild and Ant/Nant seem similar. Both tools use XML as their project serialization format, and both tools use tasks as their atomic unit of build operation. However, a deeper look reveals differences in the two tools, some of which I describe here:
1. Ant does not provide built-in target dependency analysis -a requirement for a scalable build system
[This has no impact on build files, merely effort to write new tasks. We do leave it to tasks, but they get to implement their own logic. Having to implement it yourself adds work to the task developers, but they get to write task specific rules. Like, for example, <jspc> knows the name mangling rules to go from .jsp files to valid java source files, and ftp knows about ftp sites and time zones.]
2. Ant does not have a clear concept of a project manifest -a necessity to develop additional tools to process the output of a build system
[Ant has a clear concept of a project manifest: the build file. This is well-formed XML, and none of the many IDEs that use Ant have complained yet. What Ant does not do is provide a schema as that would destroy its extensibility model.]
3. Ant does not have a normalized concept of task inputs and outputs; a necessity for a build system to support intra-task communication.
[we do have common data structures, like fileset, but to do piping we may need to introduce more concepts.]
4. Unlike Ant, MSbuild is a secure build engine. MSBuild introduces the notion of partially trusted builds, project level sandboxing and task level sandboxing.
[Ant is a secure build engine. Most people never do this, but when Ant runs inside Tomcat, it is sandbox mode. Other embedded uses of Ant would be expected to use the appropriate security model. Note also that Ant permits one to set the security permissions on code when using the <java> task, so one can run code in a sandbox from inside Ant.]
5. MSbuild has a richer extensibility model than ant. MSBuild uses constructs not available in Java. Examples range from the ability to batch tasks intelligently, or to allowing custom tasks to specify attributes as optional or required.
[Ant has a richer extensibility model than MSBuild. Ant lets third parties add new conditions, selectors and datatypes as well as tasks. Ant allows custom tasks to support arbitrary XML elements inside the task. Finally, being open source (BSD license), Ant can be extended in ways that we cannot imagine. Any part of it can be reused or changed to meet developer needs.]
6. Ant does not have the ability to import (macro insert) parts of the project file -a necessity to factor the build system into maintainable reusable pieces and a fundamental requirement for enterprise build systems.
[Ant has the ability to import (macro insert) parts of the build file using the <import> task, which even handles target name conflicts. It also lets you invoke ant builds in other files using <ant> and <subant>. We also support XML entity inclusion for inserting arbitrary text]
---
There is something deeply misguided about faulting Ant for its lack of scalability or extensiblity. Ant is intrinsically more extensible, being open source, and its scalability is something learned over time from being used in big projects. I can only conclude that Mr Rector's deep look at ant didn't go beyond asking some MS marketing weasel why MSBuild was better than [N]Ant.
If you are going to criticise ant, criticise it where it is weak, like having inconsistent naming of attributes, no consistent failonerror settings, and lots of list-like/set-like types with no underlying class other than java.lang.Object. But dont pick on scalability or extensibility, that is just picking an argument you intend to lose.
------------------
What are we going to do now. I am feeling ruthless.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
