|This article is of interest to the following WikiProjects:|
The last point in "Limitations" is not really NPOV anymore. (Although it may be true.) Especially the last sentence doesn't seem to fit into Wikipedia's style very well. (Btw, what are you trying to say with that? What should we use instead of Java? In what language/environment is development not excessively complex?) --Jonik 19:54, 12 Jun 2005 (UTC)
- Yes, it is clearly from an unhappy user. What should be done about it? I think it could be rewritten slightly to be more unbiased, the main thing being make it a fact, rather than a limitation. artifact-driven build tools need to know about all the artifacts, where ant works on entire trees of files. Both have strength's and weaknesses. SteveLoughran 21:39, 17 April 2007 (UTC)
- When you say "the last one" might want to specify which one because I added my comment after the most current last. I figured out which one you were talking about bit considering these bullets may change... --Ilyathemuromets 16:57, 20 April 2007 (UTC)
There are 2 points in "Limitations" that are not limitations, they are really just complaints of someone with apparently different preferences. To wit:
- Ant targets don't map to artifacts. This does not limit the ability to determine if artifacts are up to date. It just means that the mechanism for doing so is different. It is not a limitation merely because you prefer a different set of usability tradeoffs.
- Ant properties can't be changed. This makes builds more repeatable and reliable because one never knows in what order targets will be run. Again, not a limitation, merely personal preference about what constitutes a valuable design tradeoff.
In short, there are valid and conscious reasons for these design choices. Noncompliance with your personal level of comfort does not constitute a limitation to everyone else. 126.96.36.199 (talk) —Preceding undated comment added 20:26, 19 March 2012 (UTC).
- I'd agree that there are "valid and conscious reasons" for both of these. The arbitrary nature of targets I'd be inclined to see as more of a feature than a bug. Immutability of properties though is a complete pain in the ant (as so often happens, a "functional" approach in a language that isn't a full-blown functional language makes for a nasty piece of work to get anything done with). This is one of the major factors in particular that cause typical Ant buildfiles to become verbose. Given the space dedicated in Steve's book to work-arounds for it, I'm sure that could act as a ref for at least some people considering this to be "a limitation".
- I don't care how either of these are described. However they should both still be described, which is why I reverted their deletion. Whether something is a limitation or not, the fact that it's a difference in behaviour from other comparable systems is an aspect worth recording. Andy Dingley (talk) 20:50, 19 March 2012 (UTC)
- Ant has limited fault handling rules, and no persistence of state, so it cannot be safely used to manage a multi-day build.
What's a multi-day build, aside from the obvious "a build that lasts more than 24 hours", which is probably not just what is meant? I don't have experience with tremendously big projects, so I'm wondering what the benefit would be of a build process that periodically stops. At least, I'm assuming that's what this is about, if persistence of state is required.
In short, could someone explain what this is about? Also, what build tools do have persistence of state? Ant was primarily designed to replace the platform-dependent "make" and associated tasks, which don't have persistence of state either, unless you go to some trouble to make intermediaries represent "state" rather than "crap that was left behind when I interrupted the build". 188.8.131.52 22:00, 6 May 2006 (UTC)
- It was probably me that wrote this; it reads like it. if you want printed backup, you could cite Ant in Action or Java Development with Ant, but of course being the author of both, its not that neutral.
- Multi-day build. We, the ant team, place priority on having things work consistently over eliminating memory leaks; indeed, some of the things that Ant runs (javac) can leak memory. If builds are short lived, say 10 seconds or even 30 minutes, memory leaks are less important. Now that Ant gets embedded in most Java IDEs, memory leaks show up faster...the eclipse team have been good at profiling Ant and providing feedback. But if ever the team had to choose between 'works well' and 'leaks memory slowly over time', we'd choose working.
- the persistence of state thing stems from the fact that too many people try using Ant as a workflow tool. GridAnt is one example, but there are others. They use ant to start programs. run long tests and generally try and manage long-lived apps. People are free to do that but its not a core use of the tool. The big problems are -does it remember where it was?, and -how well does it handle failure. Ant's world view is builds either work, or they don't. But workflows often have 'try this, back off, try something else' logic, and ant does not -and will not- make this easy.
- So no, no other build tools have these attributes. They shouldn't be used for workflow either. Edited the text to make Workflow more explicit. SteveLoughran 21:14, 17 April 2007 (UTC)
make and rm
The rm example in the part about make's non-portability is a bit unfortunate — GNU make and other makes provide $(RM), so it becomes make's, not the users, problem to find a suitable tool for deleting stuff. I never invoke rm(1) directly in my files (but tend to have other, less general things invoked by make). JöG 19:12, 28 September 2006 (UTC)
This ant task has the same name as the common java command-line utility, but is really a call to the ant program's predefined library. Most likely, this function in turn then calls the command-line utility behind the scenes, as is true of many of ant's tasks.
What does that even mean? Either it does or it does not make a call to the CLI. Since it is open source, it should be possible to clarify this point.184.108.40.206 22:13, 11 December 2006 (UTC)
- It means whoever wrote the para didn't look in the source, or ask the dev team. Ant has its own zip file classes that we think are better than Sun's as they can read and write the unix file permissions, and handle duplicate entries. Fixed the paragraph and added some examples where Ant really does call out. Note that some tasks, i.e <javac> can call libraries in-VM <javac compiler="modern" />, <javac compiler="modern" />, external java program <javac compiler="extJavac" />, or external native app <javac compiler="gcj" />. There's a helper class for every compiler that sets up the appropriate program, so developers can switch just by naming a different compiler. SteveLoughran 21:19, 17 April 2007 (UTC)
What does Ant do??
I know "make" well, and have been trying to learn "ant". I could describe the heart of make in 3-4 sentences - its targets depend upon other files and it uses time stamps to avoid unnecessary builds. All I've found about ant is that it works well with Java, and it incorporates platform independence by piggybacking on Java's system call classes. I believe it could implement something like classic make with dependsets and if or unless tests, but I'm not sure it can handle individual file compiles without matching individual targets. I suspect I may be missing the river looking for trees and perhaps ant isn't designed for build avoidance. Be that as it may, this article would be improved by:
1. explaining what ant does that allows it to work effectively with Java
2. explain how it is intended to be used...
- Once upon a time, compilers compiled a source file. They compiled one file and they needed all of that file's dependencies to be in place first. They were tiresome to use.
- So "classic" make appeared. It used an explicitly written makefile to record human-defined dependencies between components. Then it invoked the compiler for each file in turn, in the order required by the makefile. Sometimes, after some human effort, this was an order capable of building the overall set of files. Often it wasn't and the makefile had to be adjusted manually.
- This was a nuisance. So compilers became smarter, started to work out their own dependencies between source files, and could then be invoked just once to compile a whole set of files.
- Make was no longer needed for its original purpose. As it had become useful for other things too, it still hung around. Makefiles were also being used to handle procedural tasks like "compile this, then copy it over there". Some people used shell scripts instead, which were perhaps better at the procedural stuff, but didn't have an inherent ability to understand dependencies.
- Ant (and others) were produced to do this better. They abandoned the original need of make (to manage dependencies between source files) as the compilers were already doing that perfectly well. They enhanced the management of the procedural side. Most importantly, Ant understands dependencies. It doesn't do dependencies between files (its tasks do that fine within themselves) but it does have freely definable, mutually inter-dependent "targets" within the buildfile and Ant understands how to linearise the graph of these dependencies and make sense of it, executing the tasks needed and in a correct order. Then it takes a verbose great buildfile to do so!
- Maven does much the same - but Maven does it by using an implicit invisible buildfile that only Maven and Maven mavens can see. Maven's dependencies work by arcane rules of 'convention not configuration', so Maven always knows what it's going to do itself, but developers using it dont. Newbies are OK, because simple projects are simple. Experts are OK, because theyve already memorised the invisible buildfile. With Ant though, almost anyone can take a pre-existing buildfile and read it to understand whats going on, even if they wouldnt liek to set it up for themselves. Most Maven projects just stick with the default structures, or lack of structure, because if anyone tries to improve it, Maven stops working and no one then understands how to fix it. Viam Ferream (talk) 09:10, 3 September 2014 (UTC)
How is the latest stable release retrieved?
Is it retrieved manually or automatically?
According to http://ant.apache.org it is "1.8.0" and it was released "February 8, 2010".
I think somebody made a mistake and thought, that Apache Ivy is Ant (which it is not). I will revert to Version 1.8.0
I know this has been said before but, Limitations?
- "XML is bad because I can't work the syntax" is certainly a bad, albeit common, argument.
- "Ant's XML is less terse than Maven" though does have some basis. Andy Dingley (talk) 14:26, 7 October 2012 (UTC)
It would be nice if the Ant release history would be documented here, like
- Ant 1.1 was release on date …
- Ant 1.8.2 was released on date …
- Ant 1.9.0 was released on date …
- Ant 1.9.1 was released on date …
- Ant 1.9.2 was released on date …