Maven by Example
We’ve spent a great deal of time on topics not directly related Maven to get this far. We’ve done this to present a complete and meaningful example project which you can use to implement real-world systems. We didn’t take any short-cuts to produce slick, canned results quickly, and we’re not going to dazzle you with some Ruby on Rails-esque wizardry and lead you to believe that you can create a finished Java Enterprise application in "10 easy minutes!" There’s too much of this in the market, there are too many people trying to sell you the easiest framework that requires zero investment of time or attention. What we’re trying to do in this chapter is present the entire picture, the entire ecosystem of a multi-module build. What we’ve done is present Maven in the context of a application which resembles something you could see in the wild—not the fast-food, 10 minute screen-cast that slings mud at Apache Ant and tries to convince you to adopt Apache Maven.
If you walk away from this chapter wondering what it has to do with Maven, we’ve succeeded. We present a complex set of projects, using popular frameworks, and we tie them together using declarative builds. The fact that more than 60% of this chapter was spent explaining Spring and Hibernate should tell you that Maven, for the most part, stepped out of the way. It worked. It allowed us to focus on the application itself, not on the build process. Instead of spending time discussing Maven, and the work you would have to do to "build a build" that integrated with Spring and Hibernate, we talked almost exclusively about the technologies used in this contrived project. If you start to use Maven, and you take the time to learn it, you really do start to benefit from the fact that you don’t have to spend time coding up some procedural build script. You don’t have to spend your time worrying about mundane aspects of your build.
You can use the skeleton project introduced in this chapter as the foundation for your own, and chances are that when you do, you’ll find yourself creating more and more modules as you need them. For example, the project on which this chapter was based has two distinct model projects, two persistence projects which persist to dramatically different databases, several web applications, and a Java mobile application. In total, the real world system I based this on contains at least 15 interrelated modules. The point is that, you’ve seen the most complex multi-module example we’re going to include in this book, but you should also know that this example just scratches the surface of what is possible with Maven.
This chapter explored a multi-module project which was more complex than the simple example presented in Chapter 6, A Multi-module Project, yet it was still a simplification of a real-world project. In a larger project, you might find yourself building a system resembling Figure 7.5, “Programming to Interface Projects”.
When we use the term interface project we are referring to a Maven
project which contains interfaces and constants only. In
Figure 7.5, “Programming to Interface Projects” the interface projects
big-webapp are written to the interfaces defined in
then it is very easy to just swap in another implementation of the
persistence library. This particular diagram shows two implementations
persist-api project, one which stores data in an XML
database, and the other which stores data in a relational database. If
you use some of the concepts in this chapter, you can see how you
could just pass in a flag to the program that swaps in a different
Spring application context XML file to swap out data sources of
persistence implementations. Just like the OO design of the
application itself, it is often wise to separate the interfaces of an
API from the implementation of the API into separate Maven projects.