...
Eclipse is not good at building artifacts, and Maven has no editors or debuggers. However, if you combine the two, then you have full coverage for the entire application development cycle.
However, since the two tools were developed independently of each other, they have different strategies and conventions. There is an area of overlap that fortunately covers almost all the function needed for our application development, but it is important to understand the boundaries. Maven has a particular directory structure while Eclipse can handle any directory tree, so you use the Maven convention to layout the project. Use the Maven POM to describe the project and let Eclipse read that file and automatically configure its view of the project. However, it will not be long before you configure at least one Maven option that Eclipse does not understand to do something Eclipse cannot exactly duplicate. Since Maven is going to build the code that actually runs in production, you need to also use Maven to build exactly the same code in development, but once you use any option that Eclipse cannot understand or duplicate, you have to bypass the Eclipse automatic compile-and-debug cycle and create a new hybrid Eclipse-Maven-Debug process that you run manually.
This document began as a set of instructions for developing the Central Authentication Server application (CAS) using Maven and Eclipse. Several releases of CAS, Maven, and Eclipse later it is clear that any static instructions will not solve the problem. However, to do better it is necessary to explain a bit about how Maven and Eclipse work and just what you can expect from the combination. CAS will remain the example used when explaining configurations and options, but this information may be useful to people doing other types of software configurationAt Yale, Maven is not optional. The software development and deployment conventions mandate the use of Maven to build any Yale application. Eclipse, on the other hand, could be replaced by some other IDE (or a text editor if you really object to the modern world). So any Yale software has to be a Maven project with a pom.xml file and the directory structure mandated by Maven conventions (Java source is in src/main/java and Web files are in src/main/webapp). It is also a Yale convention that projects be stored in Subversion.
If you check out a Subversion directory into an Eclipse project in the workspace, and the directory contains a pom.xml file, then the Eclipse support for Maven (called "M2E") can read the POM file and configure the Eclipse project to approximately duplicate Maven conventions. That is, Eclipse will be told to compile source files from the same directories where Maven expects source, and to put the output class files in the same directory where Maven would have put its class files. M2E will also download JAR libraries listed as dependencies into the Maven repository and will create an Eclipse Build Path that uses these dependency JARs to resolve references during compilation.
However, Maven has a large library of special purpose or extended function "plugin" modules that can be added to do extra processing steps. M2E supports only the most commonly used processing to compile Java and build JAR or WAR files. It does not duplicate the full capability of batch Maven to run preprocessors, generate source files, or perform special packaging steps. For certain projects you may have to run Maven once in batch to generate all the files, then do a little manual configuration of the Eclipse project to add things the standard M2E could not configure.
For example, CAS uses the "WAR Overlay" technique supported by Maven. One Maven project builds a vanilla CAS WAR file with no Yale code. A second project contains all the Yale customizations. The second project is applied as an "update" to the WAR file generated by the first project. Files in the second project with the same name replace files in the first project, while new names add new files.
Eclipse does not understand the "WAR Overlay" type of processing. It sees two projects that each produce a WAR file. It does not understand that the output of the first project will be changed using files created in the second project. So Eclipse produces two WARs, one useless to Yale because it is vanilla code and the other useless because it contains only the Yale modified files but is missing all the unmodified HTML and XML files in the first project. Eclipse cannot build a working CAS application, for that you need to run Maven in batch. However, M2E can configure Eclipse so that all the source files can be edited and the other source files and dependency JARs have been properly linked in so autocomplete and all the other IDE tools work properly.
Every new release of Eclipse changes the set of features that are automatically included and those that have to be manually installed. Furthermore, the Maven integration of M2E gets a bit smarter in each release. Generally this makes things simpler and there are fewer extra steps to get a useful development environment. However, a "cookbook" style list of specific instructions will not be exactly correct in the next release, so these instructions will be a bit more descriptive of the how and why so you can adapt if the exact steps change from year to year.
This cannot be a serious introduction to either Maven as a comprehensive project building utility or Eclipse as an IDE. There are books that cover the intricate details of each. However, it will cover a bit more than the two page tutorial that you find with either system. Move though the material sequentially and skip pages that cover material with which you are already familiar, although the objective here will be to provide more explanation than you normally get about how things work. By design, each major topic has its own URL that you can bookmark or link to.