Java Reference
In-Depth Information
My own experience isn't so black-and-white. I find that if a project was designed using
Maven from the beginning, it tends to work well with the system. It's also hard to use that
system without Maven. On the other hand, adding Maven to a system that wasn't started
with it can be quite painful. In addition, friends have also assured me that once a system
gets above a certain size, the whole process becomes an unmanageable mess.
Perhaps the best way to stay above the fray is to say that Maven has a highly opinionated
API. To be successful you have to do things the Maven way. Plus, like Ant, you're coding
your build in XML, which is never easy. The multi-project build capabilities are awkward,
7
Admittedly that doesn't sound terribly “above the fray,” but at least I'm trying.
I will note that the standard Maven project layout (shown in
figure 5.2
) has become com-
mon throughout the industry. Also, people may complain about Maven's approach to de-
pendency management, but I haven't seen anything dramatically better. Gradle (the pro-
posedreplacement,discussedlaterinthischapter)usesMavenrepositoriesandIvydepend-
ency management and suffers from the same “download the internet” problem. Dependen-
cy management is just hard, no matter how you approach it.
Figure 5.2. Standard Maven project structure used for the application in this section. Compiled sources are in src/
main/java, and tests reside in src/test/java.
Returning (at last) to the core theme of this topic, the goal of this section is to show you
how to incorporate Groovy into Maven builds. There are two ways to do that. I'll start with
the Groovy-Eclipse plugin and then build the same application using the GMaven project.
