...
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 artifactsThe source has to be stored in Subversion. The WAR has to be stored in Artifactory. Then the Jenkins Install job copies the WAR from Artifactory to the server where CAS will run and applies last minute changes to set database URLs and passwords. Eclipse cannot build the WAR artifact, and Maven has no editors 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 So you use both Eclipse and Maven to develop applications.
Yale standards require the use of Maven to build any Yale every application. Eclipse, on the other hand, The Jenkins Build Job runs Maven and expects to end with a WAR file in Artifactory. Eclipse could be replaced by Netbeans or Intellij or 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). The developer has to check this project into Subversion. How you edit it is up to you, but Eclipse is the recommended tool.
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 filethe Eclipse configuration files are typically not checked into Subversion (this is not a hard rule, but you will typically find it is true). This means that if you start with an empty Eclipse workspace and check the project out, then the Eclipse support for Maven (a component called "M2E") can has to read the POM file pom.xml file, apply the Maven conventions, and configure the Eclipse project to approximately duplicate Maven conventions. That is, .project and .classpath values. Eclipse can operate on Java source in any directory, but it is a Maven convention that the source be located in the src/main/java directory. 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 It also has special configuration parameters that are specified in the Plugins section of the pom.xml file. M2E does not guarantee that it will understand and duplicate the function of every plugin or every configuration parameter. It gets a bit smarter in each release, but you still may have to go back and manually tweak some parameters, such as the version of Java (1.6, 1.7. 1.8) that you want the compiler to use when processing the source.
If your project uses special Maven steps to generate Java source (from WSDL for a Web Service) then you have gone over the border beyond what M2E can do automatically in Eclipse. At this point you 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 configuremode ("mvn install") to get the extra processing steps that M2E cannot handle, and then you may need to manually configure the generated source files as a new source directory to Eclipse.
For example, CAS uses the "WAR Overlay" technique supported by Maven . One Maven project builds a vanilla CAS batch. You can Google for the term, but WAR Overlay is triggered when the pom.xml that generates a WAR file lists another WAR file as a dependency. CAS has a vanilla cas-server-webapp project that generates a template 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 or customizations. The CAS development convention is to build a second WAR project that contains only Yale code and customizations, but does not duplicate all the HTML and Spring XML files in the first project that contain no Yale changes. Because the Yale project lists the vanilla WAR as a dependency, when Maven batch runs the second project it automatically includes all the files from the vanilla WAR, but it replaces vanilla files with Yale customized files that have the same name and it adds any new Yale 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 properlybuilds the vanilla WAR correctly, but then when it runs the Yale project it creates a WAR file that has only the Yale files in it and does not merge the Yale modifications on top of the vanilla files. So the WAR it generates is incomplete and cannot run successfully. Eclipse cannot build CAS, so you have to run Maven in batch ("mvn install") on its own or under Eclipse to get the full WAR Overlay processing and generate the correct Yale artifact.
However, although Eclipse does not really know how to build the CAS WAR, it does correctly configure the dependencies, the Build Path of JAR files that the Yale code needs to compile correctly, and provides an editor with autocomplete and class hierarchy and all the rest of the tools that make editing and debugging easy. That is the part that M2E does correctly, and that is the only part that is really necessary.
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.
...