Eclipse is an IDE (Integrated Development Environment) with editors, debuggers, and panels to view type hierarchies and show all uses of particular classes and variables. It is an excellent tool to edit and devleop debug software, including J2EE applications. However, when you finally have your program running, it provides no good support to package your code for production deployment or general distribution. When you work with Eclipse, all you really see is the source. When you edit and save a source file, Eclipse compiles the code and "pushes" this source change even to the point of hot deploying the change into a running Application ServerWith Eclipse you can check out the current version of source from Subversion, make changes to the code, test the changes, and check the modifications back into Subversion.
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. However, it
Eclipse is not good at building artifacts, and Maven has no editors or debuggers to do development.
These two tools handle entirely different ends of the software development process. Each concentrates its energy doing a specific function that the other tools ignores entirely. Together, they provide fairly good coverage of the entire software development cycle.
Maven and Eclipse were developed separately to do different things according to different strategies. Where Maven has specific demands, Eclipse is completely flexible and can adapt to them. Where Eclipse has specific demands, Maven is flexible and can adapt. For them to work together optimally, you just have to create a hybrid environment that reconciles the two distinct philosophies. 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 configuration.
...