 | Level: Introductory Gilles Dodinet (gdodinet@karmicsoft.com), Research and Development Engineer and Consultant, Karmic Software Research
24 May 2005 Maven is gaining recognition as a general build system and is beginning to outrun Java™ technology. This article isn't intended to be a Maven tutorial. It compares Maven to other technologies and gives you insight to where Maven and Eclipse meet, and how you can make these tools collaborate.
In the past year, Maven has become more than a buzzword in the Java world. Maven has been a pioneer in the build-tooling area since 2001. In its early years, it was often compared to Ant. That may seem natural because Maven and Ant have noticeable similarities. For example, in both cases, XML scripting is available; both tools can produce artifacts; and they also share some taxonomy and concepts, such as project, targets vs. goals, and depends vs. prereqs. But they're very different in nature. Where Ant is only an XML scripting tool, Maven is a general build tool, focused on the notion of a project object model (POM). The POM exposes coarse-grained build-oriented tasks called goals, which provide guidelines that help you develop a building methodology and implement best practices.
In some ways, Maven belongs to the software factory tool family (see Resources), although it remains at the periphery. More precisely, build tools like Maven are necessary within the software factory realm.
Software factories
Software factories provide a less-expensive and more reliable approach to application development by significantly increasing the level of development automation. According to the Software Factories Web site, "A software factory is a software product line that configures extensible development tools ... with packaged content ... and guidance, based on recipes for building specific kinds of applications" (see Resources). A software factory revolves around three main concepts:
- A schema, which provides metadata that describes the structure of the different artifacts composing the application and how they interact
- One or more templates that provide starter kits and anything needed to build the application
- An extensible development environment used to configure, customize, and assemble the components
Today, such tools are gaining increasing attention from tool makers and developers, and software editors who recognize their value. These tools promote industrialization of the software development process, and reduced costs and time to market, allowing increased productivity and faster reactions to demands for evolution.
Take a closer look at Maven's main features, and you'll recognize the analogy between Maven and a software factory: Maven uses the POM as metadata to describe a project structure and obtains extensible project templates through the genapp plug-in. Due to Maven's flexibility and open nature, it's easy to extrapolate and imagine integrating Maven as a core component in a software factory platform. But that's another story. The analogy isn't complete because today Maven lacks a dedicated development environment that would help create domain- or enterprise-specific plug-ins and templates, and let you configure projects easily or customize behavior.
However, Maven's primary goal is to standardize the build process, and bring quality and easy reproducibility in the code-build-test-deploy (CBTD) cycle. It can also produce metrics to help you understand development state. The CBTD ontology isn't new in the software engineering domain, but Maven lets you standardize the ontology and envision it as a whole entity by abstracting it. Standardization is an urgent need, given the ever-growing complexity of projects. This extended build concept, which we'll refer to as a meta-build, is being recognized as invaluable, bringing quality to the next level. Continuous integration builds on this concept, but this also implies the ability to build outside the context of an IDE.
A blurred borderline
Everyone involved with Java technology has heard about Eclipse. Since its first version in mid-2001, Eclipse has matured to the point that it's an integrated development environment (IDE) of choice, especially for -- but not restricted to -- Java developers. It's an open, language-neutral platform that is also used as a base platform for educational and research projects, some of which have been donated to the Eclipse consortium (see Resources). Just as Microsoft® has taken the software factories approach, the Eclipse consortium is moving in the direction of model-driven development (MDD), and a proposal for a new project -- Model Driven Development Integration (MDDi) -- has recently been published. According to the proposal, "The Eclipse MDDi project is dedicated to the realization of a platform ... designed to support various modeling languages (Unified Modeling Language or Domain-Specific Languages), and model driven methodologies."
Increasingly, tools assume that features are fully and smoothly integrated, and Maven and Eclipse (even as a simple IDE) are no exceptions. Thus, at first glance, they seem to overlap from a building point of view, as Figure 1 demonstrates.
Figure 1. Extended build concept
Figure 1 visually describes the extended build concept discussed earlier. The overall process includes several tasks and represents an instance of a meta-build, as defined previously. Tasks can be either of two types: atomic tasks are fine-grained and context-agnostic, and two instances of such a task are barely different; and macro-tasks are composite tasks, acting as containers for micro-tasks.
A build, in its extended meaning, deals only with macro-tasks; atomic tasks are triggered depending on the configuration. This means the user has a higher-level view of the system, making the system easier to maintain and evolve.
In addition, both Maven and Eclipse are open and can easily be extended through plug-ins to fit your needs. But the similarity between them ends at that point because they don't target the same audience: Most Eclipse end users are developers; whereas, Maven primarily targets build managers. Despite that, Maven is a command-line tool. Although a graphical user interface (GUI) is being developed under the direction of Jason Van Zyl (Maven's creator and architect), Maven currently has no specific GUI to help users perform such tasks as creating or updating configuration files, or launching a build in a single mouse click.
The typical build sequence described above isn't as smooth in Eclipse as in Maven. Eclipse's very nature as a development environment adds discontinuity to the process, due to the human factor: Tests aren't always run after each successful compilation, all tests aren't necessarily run at once, some micro-tasks may be skipped, and so on. This variation may introduce discrepancies, and that's why developers have to run the complete build sequence at least once a day to ensure that they haven't broken anything.
However, because Eclipse is an extensible platform, supported by a wide user community, it made a perfect candidate to host Maven-driven development, letting developers and build managers cooperate in a simple way.
Integrating Maven into Eclipse
Mevenide is a Codehaus-hosted project that aims to simplify Maven's use by integrating it into the most-used IDEs (see Resources). As of now, Borland Software's JBuilder, NetBeans, and Eclipse are supported. Other projects partially integrate Maven into Eclipse and, thus, share some features with Mevenide -- Maven Workshop, for instance. Beyond increasing Maven's ease of use, why are such plug-ins required?
Mevenide for Eclipse enhances productivity by providing tools and views that let you hide part of Maven's complexity and improve collaboration in a team environment. From a collaborative perspective, the most useful feature is the bidirectional synchronization between Eclipse project metadata and Maven's metadata, assuming the build has already been Mavenized. What if a developer forgets to update the POM after adding a dependency in Eclipse? What if refactoring isn't propagated to Maven? The build may break, or some unit tests may be excluded, so there's a real need to keep Eclipse and Maven metadata synchronized. Mevenide listens to metadata changes and allows you to identify metadata mismatches easily, thus preventing the build from being badly damaged.
But the POM isn't only about dependencies and project layout. It also contains nonstructural project management information, such as version number, name, ID, and source repository location. Eclipse metadata doesn't always reflect all this information. So, you need another way to edit it. For that purpose, Mevenide provides a graphical editor that eases POM maintenance and lets you avoid tedious, error-prone manual editing of raw XML. Each POM semantic section is represented as an editor page, which enhances the global readability of the model. In addition, to minimize the tiresome process of POM creation, Mevenide has a fairly simple and extensible POM template mechanism.
The ability to run Maven from inside Eclipse is the least you can expect from a plug-in like Mevenide. You can choose tasks to execute (goals, in Maven terminology) -- tasks that are globally defined through Maven plug-ins or tasks that are project-dependent -- or you can customize the build by defining build-sensitive variables. Only relevant options are shown (that is, relevant in the context of an IDE), and the build log is printed on the Eclipse console, as for any other plug-in. This feature is important because it avoids the continual round trip between the console and Eclipse.
Mevenide integrates many other helper features, but they're less important. For instance, you can define relationships between given goals and file patterns so those tasks can be incrementally activated depending on workspace change deltas. You can also browse artifact repositories or search for a given artifact by name (an artifact is the result of a build; it may be a JAR file, an executable, or a complete Web site). You're then redirected to the Mevenide site for a complete list of features.
However, one issue remains: Even though Mevenide enhances productivity and ease of use, you must be aware of which tool fits your needs in particular circumstances. Running a Maven session through the Maven Console might be time-consuming, so, for the sake of productivity, during a coding session you should instead use the JUnit-integrated Eclipse support to run tests and rely on Eclipse's internal compiler to produce executable files. But before you commit anything into the source repository, you should ensure that the POM is synchronized and roll back any unneeded .classpath or .project modifications -- that is, if these files are under source control, which may be controversial; this topic is discussed in Martin Van den Bemt's blog (see Resources).
Summary
Although Maven and Eclipse have different natures, they can overlap from a building point of view. Their opposition appears considerable, but we can overcome it easily, and, in the end, efforts to make them cooperate form a fertile field. Tools such as Mevenide let Maven and Eclipse collaborate smoothly and keep them synchronized, but you must remain aware of which tool best fits your needs in a given phase of development.
Although Maven is gaining recognition as a key factor in quality processes, its integration into development environments -- especially Eclipse -- needs to be improved to make Maven a first-class IDE citizen. Until then, we can think of other Maven use cases, such as tighter integration into the global development process, and how an extensible environment like Eclipse can help implement them.
The next part of this series will take a closer look at Mevenide's capabilities and how you can use this tool to implement best practices and bring out the best from Maven and Eclipse.
Resources Learn
Get products and technologies
-
Download the Mevenide Eclipse plug-in and other related Maven plug-ins.
-
Get evaluation products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere® and start building applications and deploying them on IBM middleware. Select the Linux® or Windows® version of the Software Evaluation Kit (SEK).
-
Innovate your next open source development project with IBM trial software, available for download or on DVD.
Discuss
About the author | | | Gilles Dodinet has worked several years as a Java 2 Platform, Enterprise Edition (J2EE) consultant. Since 2004, he has worked on a .NET component-assembling tool as research and development engineer for KarmicSoft. He's an experienced Eclipse developer and a Mevenide committer. Contact Gilles at gdodinet@karmicsoft.com. |
Rate this page
| |
