...
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.
The source has to Eclipse is not good at building artifacts, and Maven has no editor or debugger. 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. The WAR has Artifacts (JAR and WAR files) are similarly required to be stored in Artifactory. Then the 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 WAR artifact from Artifactory to the server where CAS will run and applies last minute changes JBoss deploy directory plugging in values from properties files or operator parameters into text configuration files to set database URLs and passwords. Eclipse cannot build the WAR artifact, and Maven has no editors or debuggers. So you use both Eclipse and Maven to develop applications.Yale standards require the use of Maven to build every application. 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). 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.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.
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 the 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") has to read the pom.xml file, apply the Maven conventions, and configure the Eclipse .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.
...