Talk:Apache Ant

Limitations

I firmly believe the neutrality warning at the head of this section is inappropriate, damaging to the cause of furthering knowledge and should be removed. We must distinguish between irrational bias: the unbalanced or disingenuous presentation of evidence or a misrepresentation of facts; and bias where a choice is based on facts. For example: Am I being biased if I favour a hard, rugged head protection in a construction site over a baseball cap for protection? That is an extreme example to make my point that showing a propensity based on evidence is not necessarily an opinionated bias that we must always avoid. In this case, the author makes legitimate criticisms based on evidence. These have been balanced by the discussion on the purpose and function of ant in the remainder of the article. It would be a tragedy to remove the considerations listed here for the sake of blindly following a rule. To consider removing these limitations from publication would be to lose sight of the spirit of the rule on neutrality. In short, listing valid, legitimate limitations based on evidence or facts is not necessarily a breach of neutrality. To blindly remove accurate criticisms as a result of not properly appreciating the point of a rule, would make the knowledge landscape a poorer place for us all. Please think and do not lose sight of the point and purpose of rules. I hope that makes sense but am happy to elaborate if necessary. — Preceding unsigned comment added by 163.171.8.4 (talk) 09:45, 19 June 2018 (UTC)

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. 174.47.62.3 (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)

Multi-day build?

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". 82.92.119.11 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)

Weasel

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.82.10.159.229 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...

70.181.110.223 (talk) 07:58, 6 January 2009 (UTC)

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".

--Volphy (talk) 14:59, 10 February 2010 (UTC)

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

--C.Oezbek (talk) 15:30, 1 March 2010 (UTC)

I know this has been said before but, Limitations?

If XML is a limitation to makefiles, there's something wrong with you. (I know this is my viewpoint, but this is like a speech from Mitt Romney) --Stijn Brouwer (talk) 13:18, 7 October 2012 (UTC)

"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)

Good point. See whether my 2014-01-03 edit successfully addresses your complaint. -AlanUS (talk) 16:58, 3 January 2014 (UTC)

Release History

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 …
• etc.

Ernstdehaan (talk) 08:48, 11 October 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Apache Ant. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20090108131210/http://www.objectstyle.org/confluence/display/WOL/WOProject-Ant to http://www.objectstyle.org/confluence/display/WOL/WOProject-Ant

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 21:41, 7 July 2017 (UTC)

Cross-platform ... again

Hello.

There is a big problem with the word "cross-platform"; it is a weasel word. I have said a lot before, but I would like to impress upon everyone here how grave the problem is. Weasel words give zero information because their description is so broadly correct that you might as well not have that description.

Virtually, you can pick any computer program and call it cross-platform. For example:

• Most Android apps are written using Java for Android VM. In that sense, they are uniplatform. But you can claim they are cross-platform because they run on both ARM and x86.
• Most 32-bit Windows apps are written against Windows API. In that sense, they are uniplatform. But you can claim they are cross-platform because they run on IA-32 and x64 CPUs. In reality, Windows Server might not run them, if its WoW64 subsystem is not installed.
• Most Java SE apps can be claimed to be cross-platform because the Java SE runtime is available for Windows, macOS and Linux. But in reality, they are written against one platform alone.

Calling a program "cross-platform" is one problem, inserting it into the |operating system= field of the infobox is another. There is no operating system called "cross-platform". And if a program is written for Java SE 9, it does not run on Windows XP. So, inserting it into the |operating system= field of the infobox isn't just giving zero information; it is also giving potentially wrong information. Add the fact that there are no binary versions of Apache Ant. (I checked, but please correct me if I am wrong.) That means running it on Windows is a Herculean task of its own merit; not every nine-year-old kid could do it.

Finally, there is one matter. I only wrote this thread, because I felt obliged to respond to an act of good faith in kind. In revision 818096430, 2600:1005:b04a:9f8:e005:aef6:666a:aad7 went an extra mile to provide a source for the cross-platform claim. So, I felt obliged to write this. However Wikipedia requires everything written to have a source, but does write not everything that a given source says. We have other requirements too. (I was talking about one all along: WP:WTA.) Also, I did check the IP address's geolocation data. I am not saying more right now, except that if the IP editor plays fair, I will play fair. (Hint: A blanket revert that brings back four typos and causes inconsistency isn't exactly playing fair.)

Best regards,
Codename Lisa (talk) 16:43, 1 January 2018 (UTC)