Related
I currently have a Maven Java 11 project that builds fine. However, I use Eclipse's implementation of the language-server for editing the code within Emacs. This works fine, everything that I really need is available.
However, my question, is how can I disable the Eclipse LSP/compiler from attempting to auto-compile the project? It's not always an issue, but often the JDTLS seems to be recompile everything all the time to the point that when I run Maven, it has to recompile everything again. At best, this is a slowdown in the develop->test cycle. At worst, I have to clean build frequently.
Eclipse has an option in its GUI which "builds automatically". I am curious, is there a text file I can toggle this setting with?
According to the lsp-java documentation, the setting you are looking for is lsp-java-autobuild-enabled.
However, if there is a way to run the tests directly rather than via Maven, it would be faster since Maven does not support incremental compiling like JDT does (ideally, compiling should be done incrementally on save and not when running the application or a test).
I have just set up Nailgun (https://github.com/martylamb/nailgun, http://martiansoftware.com/nailgun/), which is a clever piece of kit which makes the JVM hang around in memory making Java and Jython (potentially) launch more quickly.
This is great for Java, but it promises to be absolute gold dust for me for Jython, particularly during development (Jython is the best language in the world, but has a slow start-up time).
Googling to see whether anyone had tackled running Nailgun on Eclipse I found a red herring, which is "nailgun/eclipse-gtkrc" at GitHub: "nailgun" is just the guy's handle.
I also found a CS dept had in fact tackled this, at http://www.cs.dartmouth.edu/~jygsaw/getting_started.html. They seem actually to have managed getting this working for Jython, which was potentially brilliant, but unfortunately their system relies on using a BASH script (Mac OS), and I'm forced to work on Windows (W7) for the moment.
What I then did was
1) Started up the Nailgun server outside Eclipse, including jython.jar in the CLASSPATH,
2) Then I created a client.bat file consisting of a single line:
ng org.python.util.jython %1
3) Then I set up an "external tool configuration" in Eclipse called "ng_client", as per the above CS dept's instructions, except that I set the Location to the above client.bat file, and I made the Arguments: "${selected_resource_loc}" (<-- including quotes, because unfortunately at the moment I have spaces in this path)
4) I ran this "ng_client" once so it failed, but was then included in this External tools list of tools.
5) I then selected a trivial Jython py file (trivial.py) and went Run --> External tools --> ng_client.
The console showed the following result
C:\Program Files (x86)\eclipse-jee-luna-SR2-win32\eclipse>ng
org.python.util.jython "G:\My Documents\software projects\trivial.py"
recv: No error
NB "recv: No error" is in red. The program, I hasten to add, did not run.
Incidentally, for anyone interested, this led to the Nailgun server terminal giving out the following error message:
C:\Users\Mike>java com.martiansoftware.nailgun.NGServer
NGServer 0.9.2-SNAPSHOT started on all addresses, port 2113.
NGSession 1: 127.0.0.1: org.python.util.jython exited with status -1
java.lang.ClassCastException: org.python.util.JLineConsole$Stream cannot be cast
to com.martiansoftware.nailgun.ThreadLocalInputStream
at com.martiansoftware.nailgun.NGSession.run(NGSession.java:263)
Exception in thread "NGSession 2: 127.0.0.1: org.python.util.jython" java.lang.C
lassCastException: org.python.util.JLineConsole$Stream cannot be cast to com.mar
tiansoftware.nailgun.ThreadLocalInputStream
at com.martiansoftware.nailgun.NGSession.run(NGSession.java:381)
I seem to be quite close ... does any Eclipse expert have any idea how I should proceed?
PS I've also tried running a trivial Jython program outside of Eclipse. So far it always trips up the Nailgun server as above. There is a bit of evidence out there of people doing it successfully, but they always seem to be on a Linux box, not Windows. Naturally enough I'm planning to take a look at the server source code where the errors are happening in due course.
Result!
And it makes Jython start-ups super-fast. I recommend this to all Jythonistas.
As I realised eventually yesterday (PS comment), the first thing was to get Jython to run outside Eclipse.
What I found I had to do was comment out 6 lines in the file nailgun-master\nailgun-server\src\main\java\com\martiansoftware\nailgun\NGSession.java:
ll 263-265
ll 381-383
And then rebuild the jar as per Nailgun setup instructions (i.e. mvn clean install).
After this, I made a handy .bat file to run the Nailgun server ("...\jars" is the place where I put nailgun-server-0.9.2-SNAPSHOT.jar and all the other jars I want to include):
set classpath=d:/apps/jython2.7.0/jython.jar;d:/apps/jython2.7.0/jars/*
java com.martiansoftware.nailgun.NGServer
After this, to run from a DOS window go:
ng org.python.util.jython "G:\My Documents\software projects\my_jython_project\__main__.py"
And then, in Eclipse, after following the steps above for setting up ng_client, select the .py file you want to run (in Project explorer window) and go
Run --> External tools --> ng_client
NB the sys.out & sys.err output is directed to the server window... presumably this is a consequence of the changes made to NGSession.java. If the Nailgun author, Marty Lamb, ever reads this, first Thanks for this great app, and second it'd be nice if you have any comments about the changes I made to NGSession.java.
later
Some strange things happen... hopefully just teething troubles.
In particular, I wanted to use this for unit testing which, like most development, involves constantly running things over and over. The trouble is I tend to find that the classes I am developing sometimes seem to "linger" in the "Nailgun memory". I've even seen classes run an older version of themselves when the NG server is stopped and a new one started... which is utterly baffling. It tends to suggest that older versions of .class files are somehow being "cached" in the Nailgun memory when I don't want them to be. And this happens even when using the "ng-cp" option to specify CLASSPATH additions in the client, not the server!
Unfortunately this is all quite "niche": using the Jython with the unittest module, running Nailgun. Sigh.
Instead of making the code changes to Nailgun that Mike suggests doing to prevent the java.lang.ClassCastException, an alternative is to change the console used by Jython to the PlainConsole by supplying the following system property when you start Nailgun:
-Dpython.console=org.python.core.PlainConsole
This prevents the class cast exceptions and results in the console output being returned to the client rather than the server window too.
My Windows 7 machine has a quad core i7 processor. When I Rebuild my project, it takes on average 25 seconds. And when I launch the app, it takes on average 36 seconds (before the app is uploaded to the device).
I have 588 files in my project's /src folder, which includes all of my java and xml code. I've got two .so libs each 5MB and 7 jars in my /libs folder.
See my attached screenshot. As you can see my CPU is maxed out at 100% the entire time. My iTunes music pauses, and I get a "Poor Performance" pop-up in the lower right hand corner of my windows taskbar. That's how bad it is.
I'm using Android Studio 1.2.1.1
Most of the time is spent during the preDex and dex operations.
Here's what I've tried so far (separately, I haven't tried them all together):
adding gradle.properties -> "org.gradle.daemon=true"
Power Saving
Mode Invalidate Caches /
Restart Global Gradle Setings -> Offline
work Compiler -> Make project automatically
Nothing has worked yet. I can't imagine that this is a common problem, am I right? Am I being too imaptient because this really is that much slower than Eclipse?
I guess my questions are:
Could this be due to the size of my jars or so files?
I tookover a project that had many nested views in XML files. Could this be causing a problem?
I'm really reaching for straws so if anyone has any information, esepecially why the dex operation is taking up so much CPU, that would be awesome.
I guess it goes without saying that this is happening if I edit an XML file, do a rebuild, and then launch the app. If there's nothing to clean and rebuild...
when I just do a Make Project... the average build time is 3 seconds.
Here are the three improvements I was able to make:
I was preDexing my JARs every time I built the project, so I found this solution:
dexOptions {
preDexLibraries = false
}
I was using the entire Google Play Services library:
compile('com.google.android.gms:play-services:+') {
exclude module: 'support-v4'
}
When all I needed was Google Cloud Messenger:
compile('com.google.android.gms:play-services-gcm:+') {
exclude module: 'support-v4'
}
In Eclipse, I would always do a Rebuild and then launch app with the play button. In Android Studio, now I am just doing a Clean and then launch app with the play button. Also the Run button in Android Studio does NOT work every time right after the Clean. This was causing what seemed to be delays because nothing was happening. So now I leave the Gradle Console open to make sure that the run button is working, and when it doesn't I just hit it a second time.
What I used to have:
Rebuild: 26 seconds
Launch: 36 seconds
Install: 15 seconds
and now:
Clean: 8 seconds
Launch: 22 seconds
Install: 15 seconds
which is a major improvement! Hopefully this helps someone else.
As stated on the tracker page for this issue, the team has identified this as the problem:
--parallel-threads only applies to project parallelization.
For android tasks that are running in parallel, we always create as
many threads as possible
From the page, it seems that they target release 1.3 to address this (see comment #13 there).
In the meantime, what has helped me to cope on Windows 7 is to set the CPU affinity for the Android Studio process (and its child processes) to spare at least one of the cores (as suggested by comment #9 on the page).
There are many ways to do this, but you might want to try the top-voted answer on this superuser question (which suggested to use Process Lasso) that appears to work well enough for me.
In addition to optimizations specific to Gradle (see below), I recommend that you try disabling anti-virus protection for your Gradle caches directory and your Android Studio project directory. For me, this reduces my build times by roughly 50%. Excluding those same directories from Windows Search indexing can also help.
Gradle optimizations I use, in ~/.gradle/gradle.properties.
org.gradle.daemon=true
org.gradle.jvmargs=-Xmx6144m <-- Tweak this based on available RAM
org.gradle.caching=true
org.gradle.parallel=true
kotlin.incremental=true
Note that enabling caching means you sometimes have to explicitly clear your caches when switching branches. I run this script when I run into puzzling build issues.
#!/bin/bash
# Clean Android cache
./gradlew cleanBuildCache
# Clean Gradle cache, prompting for each directory
find ~/.gradle/caches -maxdepth 1 -name build-cache* -print -exec rm -rfI {} \;
# Clean Project
./gradlew clean
# Stop Gradle Daemon
./gradlew --stop
To be honest, Android Studio is hands down better than Eclipse because of the UI designer. The downside is that it uses gradle instead of Ant. Gradle is also better but slower - especially on Windows. It runs much better on Linux. If you haven't used Linux before, fear not. Linux Mint is a stable OS that has a UI that is similar to Windows. You'll be right at home in no time. It consumes fewer resources so that leaves more processing power for the gradle build. Make the switch. You'll never go back.
Having dealt with yet another stupid eclipse problem, I want to try to get the lightest, most minimal Eclipse installation as possible.
To be clear, I use eclipse for two things:
Editing Java
Debugging Java
Everything else I do through Emacs/Zsh (editing JSP/XML/JS, file management, SVN check-in, etc). I have not found any aspect of working in Eclipse to do these tasks to be efficient or even reliable, so I do not want plug-ins that relate to it.
From the eclipse.org site, this is the lightest install of eclipse that they have, and I don't want any of those things (Bugzilla, Mylyn, CVS xml_ui), and have actually had problems with each of them even though I do not use them.
So what is the minimal build I can get that will:
Ignore SVN metadata
Includes the full-featured editor (intellisense and type-finding)
Includes the full-featured debugger (standard Eclipse/JDK)
Does not have any extra plug-ins, platforms, or "integrations" with other platforms, specifically, I don't want to deal with plug-ins relating to:
Maven, JSP Validation, Javascript editing or validation, CVS or SVN, Mylyn, Spring or Hibernate "natures", app servers like a bundled Tomcat/GlassFish/etc, J2EE tools, or anything of the like.
I do primarily Spring/Hibernate/web-mvc apps, and have never dealt with an Eclipse plug-in that handles any of it gracefully, I can work effectively with my own toolset, but Eclipse extensions do nothing but get in the way.
I have worked with plain eclipse up to Ganymede, MyEclipse (up to 7.5), and the latest version of Spring-SourceTools, and find that they are all saddled with buggy useless plug-ins (though the combination is always different).
Switching to NetBeans/Intellij is not an option, and my teammates work with SVN-controlled .class/.project files, so it pretty much has to be Eclipse.
Does anyone have any good advice on how I can save a few grey hairs?
You can download the empty Eclipse platform and then manually install the JDT tools.
Go to the The Eclipse Project Downloads page.
Choose the bundle you want, probably Latest Release.
On the download page of the chosen bundle:
Download Platform Runtime Binary
Download JDT Runtime Binary
Extract the Platform Runtime Binary archive file and run it (for example, by double clicking on eclipse.exe).
Install the JDT binary:
Click Help → Install New Software → Add... → Archive.
Choose the JDT zip file you downloaded.
Uncheck Group Items by category.
Select the Eclipse Java Development Tools.
Click next to install and restart Eclipse when prompted.
JDT from the Eclipse update site
You can also install JDT from the Eclipse update site, instead of downloading the binary.
To do this, do this following:
Skip downloading the JDT Runtime Binary, only download, extract and run the Platform Runtime Binary.
Go to the Install New Software, but instead of Archive chose the Eclipse download site.
Search and install Eclipse Java Development Tools.
The "Eclipse IDE for Java Developers" version isn't the smallest one! Look for "Eclipse Classic" - it doesn't contain most of the things you mentioned. It's larger in download size only, because it comes with source code.
See this comparison: http://www.eclipse.org/downloads/compare.php
You can use a thirdparty distribution builder like Yoxos and download just what you want.
A bit late to this party, but I asked myself the same question for a while, and while now I'm back to a more fully-fledged Eclipse installation, I used to to the following to streamline it a bit. Hope it helps.
What I Needed
Functionalities:
Java Support
Java + Java EE (XML) + Debug Perspectives
Pretty much it. There's a lot of other things I like to use in Eclipse, but I needed to keep it down to the skinniest possible because I was in a 3GB environment where I also needed to run other servers in parallel, so I couldn't afford much.
Resulting Perspectives:
Lightweight Java
Lightweight Browser (fairly tweaked for code reviews and code inspection - that one was actually heavier than the others)
Lightweight Debug
What I Did
Install Eclipse Java EE (install classic if not caring about the Java EE/XML bits)
disable hungry views
disable outline (when you need one, just do CTRL+O)
disable call and type hierarchies
disable decorators
disable menu entries (right-
disable toolbar items
even better: hide the toolbar
disable hovers and actions associated with that
disable spell-checking
disable XML validation
disable Mylyn
disable non-needed search forms in CTRL+H dialog (I usually actually only use the "File Search" mode, sometimes the "Java" one)
disable usage reporting
disable unnecessary plugins or features
disables perspectives and plugins loaded automatically on startup
restrict internal limits:
some views have a scope (enclosing class, project, working set, workspace...)
some views and UI elements have boundaries (console/loggers, highlighters, markers...)
tweak the eclipse.ini to:
-clean the workspace (slower, but I tend to prefer to do that)
use G1GC
reduce memory usage (I noticed that I can perfectly live with -xss128k and -xmx384 with G1, for instance. YMMV, of course, as always with JVM tuning.)
use a server VM (and point directly to the VM's DLL)
Also disable views you don't need in the "Debug" and "Code Browsing" perspectives.
Sorry, I had actually saved all of these as a set of 3 lightweight perspectives to re-import everytime on my new project, but I cannot get my hands on them at the moment. If I ever find then, I'll add a link to them here.
Instead of going for a ready package from Eclipse Downloads, from the same page go for the Eclipse Installer. Currently available for Mac, Windows & the beloved Linux. Launch the Installer which should update (or not if you are lucky enough :) ). Select "Eclipse Platform" which is the absolute minimum from this IDE, set your other installation preferences and install.
After the download/installation process, I'd suggest your head to Help->Install New Software and search for the Eclipse Marketplace (Yes, even that is not included in this package) just to make your life a bit easier.
Get as minimal an installation as you can, and then remove whatever is left that you don't want.
Longer answer:
I played around a bit. Here's how I experimented:
Extract a clean eclipse*.zip to two different directories; call it eclipse and eclipse-bak. We'll only modify eclipse.
Before starting it the first time, remove some of the features from the features folder. I got rid of org.eclipse.cvs, org.eclipse.epp.\*, ...mylyn\*, ...wst\*.
Start up Eclipse to a workspace. Create in that workspace a Java project, debugging configuration, etc. Stuff that you would want to do and that will complain if we remove the wrong thing. Open up the Error Log view.
Close Eclipse. Remove something (or a group of things) from the plugins folder.
Open Eclipse. Check the error log to see if something you care about couldn't load. If it did, add those things back from eclipse-bak/plugins. If not, close Eclipse and return to step 4 for a new set of plugins.
Using this I got my configuration to still be able to edit and debug Java files, but including only these plugins:
com.ibm.icu*
org.apache.*
org.eclipse.compare*
org.eclipse.core*
org.eclipse.debug*
org.eclipse.draw2d*
org.eclipse.ecf*
org.eclipse.epp.package.java*
org.eclipse.equinox*
org.eclipse.help*
org.eclipse.jdt*
org.eclipse.jface*
org.eclipse.ltk*
org.eclipse.osgi*
org.eclipse.platform*
org.eclipse.rcp*
org.eclipse.search*
org.eclipse.team.core
org.eclipse.team.ui
org.eclipse.text
org.eclipse.ui*
org.eclipse.update*
org.hamcrest*
org.sat4j*
Most of that is core stuff, but you might be able to trim it down further. Notably gone are Mylyn, the usage collector, EMF, CVS, WST, even JUnit (though I think you should keep JUnit).
I feel you man, when working with Eclipse, the application is constantly trying to help.
Ignoring workspace corruptions, I spend my development time fighting all the "helpful" things Eclipse does.
XML is not that hard to read, but it still confuses the shit out of me when I get the XML designer.
All it does for me is add an extra manual step to click on the source tab.
Every time a new version of eclipse comes out they redesign the front page and the distributions.
At which time a new quest starts for finding a way to debloat Eclipse again.
I have the same experience with extensions to Eclipse by third parties and avoid them if at all possible.
WTP has somewhat usefull stuff, but overall I prefer a basic java eclipse.
It is a good idea start with the Platform Runtime Binary and add JDT.
Manually extracting the JDT runtime doesn't seem to work for me these days, so it it better to use the update client.
You can use the marketplace client, but personally I have always found it rather annoying.
An alternative is to use the director. The director can install JDT without starting the GUI.
Here is a script that downloads eclipse Oxygen 4.7.3a and installs JDT unnattended:
#!/bin/sh
die() {
echo >&2 "$#"
exit 1
}
[ "$#" -eq 1 ] || die "exactly 1 argument required [INSTALL_DIR]"
[ -e "$1" ] && die "*warning* Aborting! location exists, eclipse already installed?"
INSTALL_DIR="$1"
TARBALL=eclipse-platform-4.7.3a-linux-gtk-x86_64.tar.gz
mkdir -p $INSTALL_DIR
if [ ! -f $TARBALL ]
then
wget http://mirror.csclub.uwaterloo.ca/eclipse/eclipse/downloads/drops4/R-4.7.3a-201803300640/$TARBALL
fi
tar -v -xf "$TARBALL" -C "$INSTALL_DIR" --strip 1
echo "\nUsing director to install java development tools, this may take a while..."
$INSTALL_DIR/eclipse -noSplash -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/eclipse/updates/4.7 -installIUs org.eclipse.jdt.feature.group
Simply call the script with one argument, the directory you want Eclipse installed.
Running the script gives me an unpacked install of roughly 129MB, which is more than 100MB smaller than the default download (zipped).
That is not to say you would not be able to shrink it further, but it should rid you of most of the crap.
The executable will be cached for future executions of the script, but it will still be slow, since it needs to go online to download JDT.
Unfortunately, I do not know of a way to cache the plugin download in a local folder.
You could of course zip the created installation, but the script is easier to commit to git.
This script will only work for new users as long as the mirror stays up and will need some updates when a new version is released.
But I am sure most developers are savvy enough to update the script if need be.
If you only want to use Eclipse for editing / Debugging Java I would suggest using a plain Text editor. It seems an overkill to install Eclipse and not use most of its features.
A very popular choice is VIM. Also check out this SO link for tips in using VIM as a Java editor. You can also debug Java code with a command line debugger as mentioned in this SO link.
I have figured out how to get the lightest possible eclipse with minimal efforts(imo). For the reference this is what I want in my eclipse:
Java project with Maven support
JavaEE support(Servers)
Debugging of Java application
(Irrespective of these you can install any feature that comes with Eclipse IDE with minimal effort, just follow the guide below)
Here's how I get it:
Go to eclipse download packages (Here's the link)
Find MORE DOWNLOADS (right hand side) and go to Other builds (Here's the link)
Now go to any build you like (Usually Latest Downloads -> whatever the first Build Name. Also There is links for older versions and archive site)
Under Platform Runtime Binary you can download Eclipse Platform as per your OS and/or requirement.
Now extract the archive and run the eclipse
Go to Help -> Install New Software...
Using Work with you can install your desired plugins and tools which usually ships with bulky eclipse
In Work with drop down select the site(mostly first) similar like this 2022-03 - https://download.eclipse.org/releases/2022-03 here 2022-03 is my eclipse version you may see different depending your version.
Now you can select the group(s) or expand the group(s) and select the specific plugins which you need and also you can filter by name like maven, debug, server, marketplace client etc in filter text input just below the Work with drop-down menu.
Install plugins and enjoy your very own lightweight eclipse.
Visual Studio Code
Fast forward to 2019 and we now can use Visual Studio Code with Java plugins. They provide a plugin pack to get you started with lightweight debugger and auto complete. Other plugins include maven integration, dependency viewer and more.
Visual Studio Code is a new(ish) editor/mini-ide from Microsoft which runs on Win/Max/Linux and has plugins for many languages.
Tutorial for setup: https://blog.usejournal.com/visual-studio-code-for-java-the-ultimate-guide-2019-8de7d2b59902
Edit 2019-06-21: MS now has a dedicated installer for Java integration with VS Code, including Spring Boot support as well. While the Intelisense is not 100%, it's vastly improved and now my go-to Java editor for testing and trying new things. Announcing the Visual Studio Code Installer for Java
I see reference of ant a lot but I don't get exactly what its meant to do? from what i've heard its supposed to compile your projects but can't i just do that by clicking Run->Run in eclipse?
Edit : I guess I should rephrase my question. I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
I already know that ant is a 'build automation software', my question is, what exactly is build automation? I thought that you're supposed to test your app, and when it is running you click the 'build' button in eclipse or through command-line java, and it makes a .jar file out of it? So why do you need to 'automate' this process?
Not all the Java development is done through eclipse and not all the jars may be built from the command line ( or should be built from the command line ) .
You may need additionally run test cases, unit tests, and many, many other process.
What ant does, is provide a mechanism to automate all this work ( so you don't have to do it every time ) and perhaps you may invoke this ant script each day at 6 p.m.
For instance, in some projects, a daily build is needed, the following are the task that may be automated with ant, so they can run without human intervention.
Connect to subversion server.
Download/update with the latest version
Compile the application
Run the test cases
Pack the application ( in jar, war, ear, or whatever )
Commit this build binaries to subversion.
Install the application in a remote server
Restart the server
Send an email with the summary of the job.
Of course for other projects this is overkill, but for some others is very helpful.
rogeriopvl is absolutely correct, but to answer your "can't I just do that by clicking Run->Run in Eclipse?" question: that's fine for a project that you're working on on your own, and don't need a repeatable, scriptable build in multiple environments.
If you're working on an open source project, however, or professional software which needs to be able to build on a build server etc, requiring a particular IDE to be running isn't a good idea.
Ant is used to automate a build process, but a build process is often much more than compiling. Ant has "tasks" that can be used to perform miscellaneous useful functions. You can create your own task to do just about anything by writing a java class and telling ant where to find it. You can then mix and match these tasks to create targets that will execute a set of tasks.
You can also set up a dynamic environment in which to build your application. You can set up property files to hold variables that can be used in the build process, i.e. to hold file paths, class paths, etc. This is useful for instance to differentiate between test and production builds where deployment paths, database instances, etc. might change. Ant also includes flow control (if, etc.)
Some things I've seen ant do:
Compile code
Use version control to checkout the latest version or to tag the version being built
Run sql scripts to build or rebuild a test database
Copy files from an external resource for inclusion in a project
Bundle code into a jar, war or ear file
Deploy a web application to an application server
Restart an application server
Execute a test suite
Static analysis, i.e. CheckStyle or PMD
Send email to a team to alert them to a build.
Generate files based on information from the build.
Example: I have a jsp in my app that does nothing but display version/build information. It is generated by ant when I run a build, and the production operations team checks this page when they deploy the application to make sure they've deployed the correct build.
In many larger companies (and likely some smaller ones), you'll find that production code is not built by the people who developed it. Instead, the developers may check their code into a source code repository and tag it. Then they give this tag to a build team.
The build team, in a separate (clean) area - possibly on some headless server (i.e. with no GUI) - will then check out the code and run a build script. The build script will be completely independent of the desktop environment/IDE.
This ensures that nothing which happens to be on any one developer's computer is "polluting" the build. (Or, more likely, nothing outside source control is required for the system to work!)
So most software you use will never, ever be built from a developer's desktop.
PS. You might also want to look at the idea of Continuous Integration
The short answer is that Ant is a great way to create a complete project build that is independent of any particular tool any developer may be using. Without an independent build, things can go haywire quickly - especially for large project teams.
And now for the long answer... I have been brought into several projects without any sense of an independent build. On one project, there was one guy who was not a developer that was tasked with building and deploying the software. He had created 147 separate windows batch files to compile each EJB, each servlet, and each client component. There was no error checking for this build. All log messages, including error messages went to standard out. It was up to him to manually recognize by reading this log which exception or message printed was a normal and which message was an error. He also had to deploy this software he just built. Deploying was equally as complex since there were several load-balanced tiers. Each module had to be placed in the right place manually with options setup to match downstream and upstream tiers. Building and deploying this software took him at least 3 days using this method. Of course, only then could anyone determine if the build "worked". Usually, after this period all the programmers would scramble to debug the build. Programmers would say my module works fine in my IDE. I just click run like this, see?
Indeed, the individual software modules usually worked, but the build and deployment was horribly ineffective. And just as bad, it was equally as difficult for anyone to deploy a build to more than one environment. Management would say, ok you now have this build working in our regression testing environment. Now deploy that same build in this other environment so the sales guys can demo up and coming software. That should be simple to do, but it also took at least 2 days, followed by a "debugging the build" period. Builds and deploys were never simple and never accurate. It really slowed the project down.
Anyway, we replaced this entire procedure with a complete Ant based build and deploy mechanism. The end result was that a complete build could be created and deployed in less than 30 minutes, completely automated. The QA guy managing the builds and deploys could keep a whiteboard of which environment had which build deployed to it and which group was using that environment. This was something that was just not possible with the old system.
Ant is for automating software build processes:
http://en.wikipedia.org/wiki/Apache_Ant
Ant allows CRISP (complete, repeatable, informative, schedulable, portable) builds. You can find great info on it in this presentation by Mike Clark and in his book, Pragmatic Project Automation.
Ant is a build tool, akin to makefiles (albeit with a very different syntax in XML). If you're only using Eclipse it's fine to stick to that and you can always convert an Ant build file into an Eclipse project (Eclipse's launch configurations are then, if I remember correctly, the equivalent of Ant's build targets).
If you want to deploy the source code of the application and allow others to easily build or set it up, automating that using Ant is probably not a bad idea. But it's usually not a consistent experience for users or at least I haven't seen much consensus on what targets should be there and doing what so far.
Ant may also be used for regular automated builds (you wouldn't want to hit Run in Eclipse every night, right? :-))
If there's one close to you I think you'd get a lot out of CITCON, the Continuous Integration and Testing Conference. You get to talk with lots of people about the benefits of automation applied to building and testing software.
Basically people use Ant (with other tools) to automate everything they want to have happen after a commit. The basic advantages of such automation are faster, better and cheaper.
Faster because things happen right away without waiting for a human to get around to it.
Better because computers are really really good at doing the same thing the same way every time. (Humans tend to suck at that.)
Cheaper because you have fewer mistake and the mistakes that occur are caught sooner and therefore cheaper to fix.
You are also referring to the ""Export ant buildfile".
If you write your own Ant script for building your application outside eclipse, you can write your own targets that use the Ant task to delegate to the generated build.xml.
Also, you can configure a project's 'builders' (project properties » Builders) to run any script (ant or otherwise) you want when you build the project, manually or automatically.
Joel (Spolsky) has a great article on "The Joel Test." Many of them revolve around being able to do important things often, quickly and reliably. One of those things is your build.
Eclipse is using ant for building, running, deploying, ...
"Ant is a Java-based build tool. In theory, it is kind of like Make, without Make's wrinkles and with the full portability of pure Java code." (from link text