...
Maven is a batch tool for building and packaging production "artifacts". An artifact may be the WAR file for a Web application, or the EAR file for a J2EE application (containing WARS and EJBs), or it may just be a component library packaged as a JAR file. In order to create the artifact, Maven will compile any source, copy data files, and even download over the internet any referenced public Java JAR libraries. Maven "pulls" all these pieces together to create the production deploy file. At Yale, artifacts are stored in a special Maven related Web server called Artifactory.
Eclipse is not good at building artifacts, and Maven has no editors editor or debuggers. However, if you combine the two, then you have full coverage for the entire application development cycle.
At 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 yeardebugger. So they are complimentary tools that handle different phases of the development process.
Yale conventions require that the source to any Yale software project be stored in Subversion. Artifacts (JAR and WAR files) are similarly required to be stored in a network server called Artifactory. Build and installation have to be managed by the Jenkins tool which runs what are loosely called "jobs". A Jenkins Build job runs the Maven project to check the source out of SVN, creates the artifact, and stores it in Artifactory. The Jenkins Install job copies the artifact from Artifactory to the JBoss deploy directory plugging in values from properties files or operator parameters into text configuration files to set database passwords or other last minute text values.
During development, Eclipse not only provides an editor and debugger, but its built in support for Maven substitutes for the Jenkins Build and Install job. However, since the desktop developer typically does not have access to Artifactory, the local Maven repository (typically in the ".m2" subdirectory of your home directory) is used instead of Artifactory during this phase of development.
Eclipse has Maven support, but it does not require that you use it. You do not have to put your source files in the Maven standard src/main/java subdirectory but can configure any subdirectory as Java source. Similarly, you can manually configure any JAR file anywhere on disk to be used to find Java classes during compile. The Eclipse project is configured with a .project file, a .classpath file, and a .settings directory. Maven is configured with a pom.xml file.
It is a Yale convention that Eclipse project configuration files are typically not checked into Subversion. Eclipse has a built in Maven support component called M2E that can read the Maven pom.xml file and create equivalent Eclipse configuration files. Since Eclipse edits and compiles, this mostly means that the .classpath Eclipse configuration file is created so that Java source in src/main/java is compiled using all the JAR files defined as a dependency in pom.xml and downloaded to your local Maven repository. Eclipse is not a tool for building final artifacts, so M2E does not support special Maven processing steps for running preprocessors or filtering files copied to the WAR.
Eclipse is an extensible development environment to which you can add additional "plugin" function. Maven is an extensible build environment with its own system of plugins. However, Eclipse plugins are not Maven plugins. Each new release of Eclipse gets a bit smarter about Maven, but there are limits. For example, before Eclipse Luna you had to manually add Eclipse AspectJ support (AJDT) to easily handle the AspectJ elements of CAS compiling. After Luna, M2E detects the AspectJ references in the Maven POM and automatically triggers the installation of AJDT into Eclipse. However, Eclipse will complain automatically that there are things in the pom.xml file it does not understand and cannot duplicate. That is typically not a problem.
If you need some Maven processing that Eclipse doesn't do (for example, to run a preprocessor to generate Java source from some WSDL) then after Eclipse creates its project (with errors due to the missing source) you run a batch "mvn install" on the project to perform the extra steps. Then you have to go back and manually define the generated source directory to Eclipse as a Java Source directory and the errors go away.
Eclipse has the ability to run Maven commands on projects. You can do a "mvn install" from Eclipse instead of from the command line. However, Eclipse doesn't do any Maven processing automatically. Instead, M2E understands Maven POM files and configures Eclipse to do Eclipse processing that is roughly the same thing Maven would do when it compiles the project source. For everything else you have to do real "batch" Maven processing using real Maven.
The Jenkins Build job checks out the CAS Server project from SVN and does a real batch "mvn install" on it. Then it copies the generated artifacts to Artifactory. With Eclipse you can define a Run Configuration named "Maven Build" that also does a "mvn install" on the cas-server project in your Eclipse workspace. This does the same processing, but the artifacts are stored only in your local Maven repository and are not copied to Artifactory.
The Jenkins Install job checks out the CAS Server "Installer" job from SVN. At Yale, an Installer job is a Maven project that runs an Ant build.xml script. The script copies the artifact to the JBoss deploy directory. In Jenkins the artifact comes from Artifactory, but if you check the Installer Maven project out as an Eclipse project in your Workspace and do a "mvn install" with it, the artifact comes from your local Maven repository where the Maven Build Run Configuration put it.
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.