While browsing this forum I’ve come across users mentioning the build tool Apache Ant. I’m wondering what the advantages are of using Ant in Eclipse over the default setup of pressing the ‘Run As’ button the default export…
Apologies if this is the wrong board.
Thanks!
Not for starting (Run As) but for building you have a lot more possibilities - since you can script the whole building process.
E.g. export your project as jar and tick the checkbox on the last step (if I remember correctly) to save the ant file. You can then modify it for your needs. I did this to automatically bundle jars next to my main jar, modify the manifest, starting proguard, etc.
For my projects ant is enough, even with its ‘ugly’ xml writing (especially for more complex things like conditions)
You should also look into maven or gradle if you are looking for a building system!
You’ll eventually need something like Ant to make anything more complex than “test toys”. It’s worth having a tinker to get a feel.
Ant is crap, btw. But I’ve never actually used anything else. Can’t be bothered - it works.
Cas 
The actual value of Ant is that it allows to collaborate with people, integrate with an automated build environment such as Travis/Jenkins/AppVeyor/… and be an enabler for continuous build and delivery:
If you build your project solely on your own in private without having a version control system and without making your sources publicly available for others to see and explore and play with, then indeed Ant or any build tool for that matter is not necessary.
But, once you start collaborating with others, a build tool like Ant becomes a necessity: First, you don’t want to tell people to use Eclipse just when they want to develop and build your project. Some like to use IntelliJ IDEA, some like to use NetBeans.
You want to ensure that no matter which IDE people use, that, whenever they build your project, everyone gets the same outcome/artifact of it.
Second, you want people to understand your project. And with it comes the build configuration. What dependencies does the project have? What Java version does it require? Are there tests being run during build? Are there any platform-dependent build steps? And all those questions.
Third, you want to give people the feeling that your project is not “broken” by assuring them that it builds on a clean machine such as Travis. When we are talking about “continuous build,” which again is only a thing when you are working on a project with others and want quick feedback about build breakers. Next, you can add “continuous delivery,” where you add the “customer” to this feedback cycle. Whenever you check-in a change into your version control system (Git, Svn, …) then a separate build server can pick up on the changes, build your project and deploy/deliver it somewhere.
Build tools like Ant are therefore enablers for all this automation, collaboration and feedback stuff.
But again: Only really necessary when you want to collaborate, automate and have quick feedback.
Try Scar if you prefer java syntax, which makes a lot more sense than xml.
Surprised nobody has mentioned Maven; from my limited experience with it, it’s Ant done right.
Great Eclipse integration too, and you can host your maven repository directly on github.
Takes a little while to get your head around the concepts, but the way dependencies are handled makes it a dream to use (especially when you’re pulling from others’ Maven projects)
Cause it sucks even more than Ant ;D
Seriously, these days it makes much more sense to start with Gradle.
That scar thing looks like the best idea tbh.
Cas
Nah
name: AwesomeLib
source:
- src
- other
---
System.out.println("The document data can be any text, ");
System.out.println("but is a convenient place to put code.");
… aaaaand there goes IDE support out of the window.
+1
triggered
I was once involved in a huge attempt to switch from big ant scripts to gradle, for huge projects with many dependencies (also some circular dependencies for some reason :emo:) but it was stopped because it got out of hand and was un-doable, at least at this time.
IME having external dependencies in a build is a bit like building your castle on sand. The build must always succeed. Discuss.
Having complex multi-layered internal dependencies in a build is a bit like what happens when n00bs discover inheritance in OOP. Discuss.
Cas
@princec
Yes, I agree - I tend to be dependency free as far as it gets. But at least if you stick to a specific version of whatever dependency it would still always compile (hopefully).
So you’re advocating the inclusion of external packages with your build, rather than having them pulled from a central repository?
I’m of the opposite opinion; pulling from a central repository minimizes data duplication, and therefore fewer places for mysterious build errors to creep in.
Either you get the correct version of the correct library, or you get nothing. Fail fast.
Yes. But you can blame both sides:
This is something which “Semantic Versioning” (one incarnation of it is here) has been trying to solve for decades. The problem is that library writers hardly adhere to a coherent convention of how version numbers should be used. There is much more “psychology” than strict formalisms involved in it.
There exist times and places that have compromised internet connections. Read in to that what you will.
Cas
Yes, you are of course right. This is no right-or-wrong here.
The solution to that is to have a local repository cache, which both Maven and Gradle have. On the other side, if you check-in your dependencies into your version control system either in the form of sources or of compiled artifacts (or you update them), then you’d have the same problem of not being able to reach the VCS to pull the latest updates.
Either way, at one point you have to have remote access to a VCS or repository to get all the stuff (unless of course you share them on a USB key or other media) 
Hi
I find Ant very flexible, it’s like a portable equivalent of Makefile. Maven requires to follow a lot of conventions, it works very well when you’re straight in the road but it may become a nightmare when you have to do something noticeably unusual. Gradle has the best of the both in my humble opinion. I use a lot Ant and it’s sometimes difficult to migrate away from it. I wrote my own tool to create native self-contained application bundles with it, it can be hardly ported to Maven or Gradle.
[quote=“princec,post:11,topic:58159”]
Build systems. They all suck.
(Some of the smaller ones out there ain’t that bad, though/because those do not want to be Can-Do-It-All monsters.)
This is actually only a mild problem with maven and gradle. If you want to see this problem in an apocalyptic scope, use npm :o
ant in the glue in maven.