What is the relationship between Eclipse .classpath file and build.xml file?

Question

I use Java/Eclipse for development and I've never really used any conventional build tools like ant or maven. I generally just rely on building projects through eclipse and I rarely use commandline. I don't really want to spend time getting to know ant/maven, but I'd like to know whether eclipse can really substitute all functionality of ant/maven through its .classpath file any other settings.

(Please don't suggest me some tutorial that makes it really easy to learn ant).

Answer 1

• Eclipse knows how to build a project based on the .project and .classpath files.

• build.xml is the default filename of build rules used by Ant, so that when you run ant without parameters, it will use this file to figure out what to do.

• pom.xml is the default filename to describe a Maven project, so that when you run mvn compile , it will use this file to figure out how to build the project.

• Eclipse can import a project based on an Ant build file or a POM file, and create the appropriate .project and .classpath files.

Eclipse, Ant, Maven are all different tools that cannot replace each other. They have some overlapping functions, but also some unique functions.

Being able to build a project using the command line is a very useful skill, and part of being a good programmer. In the Programmer Competency Matrix, being able to build your software using the command line is considered Level 1 (out of Level 0, 1, 2, 3), if you cannot do this, that's not so good. http://www.indiangeek.net/programmer-competency-matrix/

I strongly recommend to learn Maven.

Answer 2

If your applications have little existence outside of Eclipse then maybe you should keep using Eclipse in that way. But Eclipse is a developer tool (developer as in the person who writes the code). Any other than the most trivial projects have to deal with roles other than developers. and applications go through an entire life cycle. In fact, different axes of life cycles exist, whether it being from a project management perspective, from the perspective of deliverables traversing a number of phases such as coding, compiling, assembling dependencies, packaging, deployment, or from other perspectives.

When you look at those deliverables traversing phases, a lot of these steps can be done (manually) from within Eclipse. So, again, if that works for you, praise. However, it misses automation and for some steps (phases) Eclipse just ain't the right tool. For example: Continuous Integration is not something Eclipse is built for. A CI server may want to checkout your sources and build stuff from scratch. It needs to find dependencies and such, may do so on basis of Eclipse's .classpath file, but that introduces a dependency on Eclipse. Now, I've seen large companies do it exactly that way, but it's a bit clunky because that's again not what Eclipse was meant for.

Instead there's tools that are great at dealing with the entire* life cycle.

* Note that "entire" is a very subjective matter. From a developer's perspective the life cycle may be nicely split up in phases, but other people in your larger organization may find that their duties are underrepresented in any given breakdown of life cycle phases.

Maven or Gradle are such tools. Look at them as an assembly line with a number of stations. The developer is at one of the stations, using Eclipse, but underneath the assembly line keeps rolling. CI is another station, using Bamboo, Hudson, Jenkins or similar, but underneath still the assembly line at work. Within Eclipse the m2e plugin is the connector between Eclipse and the assembly line Maven.

A different approach to the matter is to use scripts, either to replace the manual steps that you're doing in Eclipse, to hook them together, or to complement them. There is clearly many languages that can be used, but within the build tooling domain Ant is wildly popular because its functionality aligns well with exactly this purpose.

If you're a professional software factory (which might already be the case for a single developer project) you need an assembly line. Maven or Gradle give you one out of the box. If you want to swim upstream you build your own, using Ant or other stuff. And if you really have no requirements in this area to speak of, keep doing things manually in Eclipse.

Even though being defined in XML, Ant comes naturally to us as developers, since it has much of traditional sequential programming languages. Maven and Gradle have a different approach, and have thus a steeper learning curve. But it is definitely worth it. If you do it their way things become a breeze and you don't have to code every other thing you want to add to your assembly line. This hand-crafted scripts always start small, but they never stay that way, do they? :)

In addition to all this, I'd like to mention that Maven is also really good at resolving dependencies. That's what it's most known for, but that's not what this question was about, and it is in fact only such a small part of what it can do for you.