I would like to introduce the m2e project, a project that combines the power of Maven with the usability of Eclipse. In this article, I'm going to talk about our plans for the m2e project: where it is today, and where we intend to take the project. M2e is more than just a Maven plugin for Eclipse. While that is certainly an important part of the m2e project, Sonatype has its eyes set on a much more audacious goal. We're using the m2e project as an effort to bring solid build automation to Eclipse by providing Maven as a solution for building Eclipse plugins and the Eclipse platform. The m2e project is helping to drive the requirements for the Maven 3 platform, driving projects such as Tycho and Mercury, which promise to change the way that developers interact with components and repositories. This article provides a quick overview of what is available today, and what is currently under development. There are many surprising and revolutionary changes right around the corner for both Eclipse and Maven.
Why m2e Is Different
What makes m2e different from the previous attempts at bridging Maven and Eclipse? Apache Maven and Eclipse have a history of integration efforts, and while there have been Maven plugins for Eclipse that predate the m2e effort, we have yet to see a solution that creates a truly integrated plugin. The previous plugins provided a mechanism to launch a Maven build within Eclipse and to configure a Maven POM with a GUI editor, but they always left something out. All of these plugins treated Maven as an external tool to be launched within the Eclipse platform. The goal of these plugins was always to use Eclipse as a shell around an external tool called Maven, but launching Maven from Eclipse is only half of the problem. What about using Maven to manage and build Eclipse components?
M2e is helping to drive changes in the Maven 3 platform and tools like Tycho that can be used to build and manage Eclipse components in Maven. Instead of viewing m2e as yet another attempt to create a Maven plugin for Eclipse, you should view it as an effort to bridge the gap between the two platforms. Sure, m2e provides a solid Maven plugin for Eclipse, but as a side-effect of the integration, it will also allow you to build Eclipse plugins from Maven in projects that reference the same OSGi components in the Eclipse platform. The m2e project is driving innovation in the Maven architecture that will enable users to interact with multiple repository formats, and, because of the work on m2e, developers will be able to use Maven to build and manage OSGi components.
When we started the m2e project, Eugene Kuleshov and I decided to sit down and dig into the details of both platforms to identify the right way to combine them. We quickly concluded that a successful integration effort would require some changes to the Maven architecture to make it more pluggable and some new development to allow Maven to interact with the different repository formats used in Eclipse development. We're well on our way to fulfilling this initial vision, and once we are done, not only will Eclipse have solid Maven integration, Maven will be a viable solution for building the Eclipse platform. M2e is different in that it isn't just bringing the power of Maven to Eclipse, it is a meeting of two rivers, a confluence, that is helping to drive innovation in both platforms.
Bringing Maven to Eclipse (and Eclipse to Maven)
As I talk with people about bringing Maven to Eclipse, they tend to use social and scientific metaphors to describe the possibilities. It's a "marriage," a "dance," an intertwined "DNA double-helix," or two galaxies colliding in a slow, violent, but entertaining exchange of mass and energy. It has been an interesting challenge to merge two technologies both with existing "opinions" and approaches to modeling projects and artifacts, yet we welcome the interesting problems as they are opportunities to take lessons learned and feed them back into Maven. We've made targeted changes to Maven based on the integration efforts, and we've made Maven more efficient and leaner in an effort to create a quicker, more responsive experience for people who might only use Maven through Eclipse. Even though we're still getting settled over at the Eclipse Foundation, you can download and use a capable and complete Maven plugin for Eclipse called m2eclipse. Even though we're just beginning, you can start using development releases of tools like Tycho to start automating your Eclipse plugins build with Maven.
The title of this section may be bit misleading, we're not "moving" Maven to Eclipse, and, you can rest assured that we're not implementing any new features in Maven that will only be available through an Eclipse-based GUI interface. Apache Maven is a healthy and growing community of individuals staying at Apache Software Foundation. Maven users who have no interest in using Eclipse will not be affected by the integration, but those who use Eclipse will reap the benefits of a powerful combination. With m2e, users can import Maven artifacts and build Maven projects without having to resort to some of the acrobatics and duct tape now required to build project and classpath references from Maven POM files. With m2e, application developers are able to create a new project from one of hundreds of Maven archetypes in a matter of seconds, and developers now have access to the Nexus repository index to search for and add dependencies with a simple click of a button. With m2e, Eclipse tool developers are able to read Maven metadata and use Maven plugins when developing Eclipse, and release engineers can build Eclipse plugins and deploy Eclipse releases using the tools produced by m2e.
You weren't expecting that last bit, were you? Building Eclipse with Maven? Maven should be able to build Eclipse, RCP, and OSGi applications without running Eclipse, just like any other Maven build from the command-line or in continuous integration. Tycho is the Maven plugin that is used to build OSGi applications in Maven, and you can run Tycho from m2eclipse, as you can with any other Maven build. The integration effort isn't as simple as allowing developers to use Maven from Eclipse, we predict that the "marriage" of Eclipse and Maven will be as transformation for Eclipse as it is for Maven. Bringing Maven to Eclipse changes everything.
Maven and Eclipse: Powerful Allies
What does it really mean to bridge the gap between Eclipse and Maven? In this section, we explore the contrasts between Eclipse and Maven, and we discuss some of the areas in which closer integration would be mutually beneficial to both platforms. We use the term axis to refer to areas in which Maven and Eclipse are compliments. Let's explore these complimentary axes:
- User Interaction
- Project Modeling
- Managing Artifacts
- Writing Extensions and Plugins
- Project Conventions
User Interaction
While Maven excels at command-line builds and automated builds, Eclipse is the gold standard for interactive builds. With Maven, understanding the output of a complex multi-module Maven build involves a text editor. With Eclipse, a large build can be managed interactively; compilation problems and unit test failures can often be identified and addressed at the click of button. While Eclipse might be great at providing interactive builds in an IDE, getting Eclipse to build in a continuous integration tool or on the command-line is challenging as tools like Cruisecontrol or Hudson expect a build that can run solely from the command-line. UI support for understanding Maven projects and dependencies has been mostly stuck in static web pages and reports. Prior to m2e, there was no good way to editing a pom.xml in a custom editor, search the Nexus repository index, and add a dependency. Maven can bring command-line build automation to Eclipse, and Eclipse can bring great visual interactivity and interactive reporting capabilities to Maven.
Project Modeling
Maven has an integrated Project Object Model (POM), while Eclipse has a distributed one. The Maven POM has all the information required to work with a project: developer names, SCM information, issue tracking URLs, dependencies, licensing information, and descriptions of components. Eclipse tends to have different metadata for each aspect of a number of different plugins with plugin metadata in disparate formats that depend on the design styles of the plugin developers. Coordinating and controlling access to these has become a friction point for tool integration just as people are starting to become interested in features like Mylyn issue tracking or ECF developer chat possibilities. There are opportunities to start bringing some of the Eclipse plugin metadata and configuration into the Maven POM.
Managing Artifacts
Eclipse makes it easy to consume and work with source, with everything from content-assist and quick fixes to support for advanced refactoring operations. With Eclipse, binaries are another matter altogether; there's little support for finding or managing the JARs your project creates or the libraries it depends on. On the other hand, Maven makes it easy to consume and work with dependency artifacts and the products of your build, with everything from registered names and versions to local and remote repositories to repository indexes that enable you to find any code or metadata in any class or POM in any repository and pull it straight into your project. Bringing the power of Maven to the Eclipse IDE allows developers to create dependency graphs, search for artifacts in a remote repository using a Nexus index of a Maven repository.
Writing Extensions and Plugins
Both Eclipse and Maven provide APIs and frameworks for writing extensions and plugins. Eclipse has a very rich model providing many integration opportunities with a large API that requires XML documents that describe a component and declare requirements and dependencies. Maven uses a simple Plain-old-Java-Object (POJO) approach for Maven Plugin development that uses dependency-injection. Bringing Maven to Eclipse gives Eclipse users access to the hundreds of plugins already available for Maven for everything from running an embedded instance of Jetty to generating reports about a project's source code. With Maven, tool developers can write tools rather than worry about where they run, and users get Eclipse support for configuration. Adapting Maven's project model to be able to model Eclipse components will allow Eclipse developers to use Maven as a build tool for Eclipse plugins and components.
Project Conventions
Where Eclipse supports an infinite variety of project structures with flattened relationships between projects, Maven encourages a common convention for project structure and supports hierarchical organization of projects. With Maven, metadata and build coordination can be specified in one parent or aggregator POM, rather than being scattered throughout a set of related projects. While both support configuration of various build steps, Maven tends to make it easier to understand an unknown project and easier to coordinate multi-module builds. Once Eclipse developers start to understand the conventions of Maven and start using things like Tycho to build Eclipse components, it will be easier for non-Eclipse developers to build and understand components and plugins in Eclipse. Bringing Maven and Eclipse together will help to expand the community of Eclipse developers by reducing the barrier to entry for someone interested in building and contributing to an Eclipse plugin.
Merging the Technology
These axes define areas where Maven and Eclipse will benefit from each other. While there may be some difficult problems to solve to fully realize a high level of coordination, I believe that both Maven and Eclipse will benefit from the effort. One particular area that illustrates a benefit Maven can bring to Eclipse is classpath containers. Because Eclipse allows plugins to define classpath containers that can be referenced in other plugins, m2e is already benefiting plugins that want to take advantage of the dependency management capabilities of Maven. With this new ability, plugins can use classpath containers provided by the m2e plugin to gain access to the classpath of projects using Maven.
One example of Eclipse transforming Maven is in the area of project metadata. Eclipse already has a distributed model of projects and dependencies. For example, an Eclipse project, which builds an OSGi bundle, may already have the prerequisite metadata available in an Eclipse-specific format. Instead of mandating that all Eclipse plugins and components maintain pom.xml files, we are building systems to assemble a virtual POM given the information in Eclipse-specific component descriptors.
Just as Eclipse allows for non-Eclipse components to supply classpath containers, Maven is evolving to allow for non-Maven providers of project metadata and dependency information. In both cases, the API changes will require plugin developers to think about a more generalized approach to interacting with both Eclipse and Maven. If you are writing a Maven plugin in Maven 3, you will no longer be able to assume that project information is going to be stored in a pom.xml, and if you are writing an Eclipse plugin you might not be able to assume that classpath information will be supplied solely by Eclipse. The integration effort is making both Eclipse and Maven more flexible, more general.
An area with the potential for conflicting approaches is in the process of project creation. With Maven, a user has access to a long list of Maven Archetypes for everything from web applications projects written in Wicket to messaging components for messaging products like Mule. In Eclipse, you create a JET template or a custom wizard to walk the user through the creation of a new type of project. In these cases, there may be healthy competition between the differing approaches used by both communities, and the communities will have to sort through issues as they arise. If anything, more integration and collaboration will mean more choices for developers in the long run.
A Confluence of Communities
As the communities surrounding Maven and the Eclipse Foundation start to interact, it isn't clear if there will be conflict over turf or synergy in common goals and complementary strengths. To traffic in stereotypes, the Maven community tends to be IDE-agnostic, to value working code over elegant design, and to value group consensus over individual leadership. The Eclipse community has a different feel, writing layered and patterned code, often valuing individual leadership over group consensus, and adhering to a strong set of opinions about how software is designed and implemented. There may be initial problems integrating the two communities, but, in the end, I predict that that effort the will succeed due to some interesting trends driving the adoption of both Eclipse and Maven: increased modularity, the desire for more agility, and a movement to adopt open-source best practices in the enterprise.
Software is become more modular, and it is more common for today's enterprise applications to depend on a large number third-party libraries. More and more projects are depending on an increasing number of open source components and libraries, and this has been driven by acceptance of the idea that open source allows organizations to both share the burden and control their own destiny. This shift has also been motivated by a move to smaller, more distributed, more modular teams. Instead of working on one project for multiple years, developers are picking up projects in an agile workplace for two-week iterations, and then moving on to other projects and other components.
In this agile, open source, and modular environment, Maven acts as an essential translation tool for developers who need to quickly switch from one project to another. Using m2eclipse, a developer can materialize a project in his or her workspace complete with Mylyn and WTP configuration from nothing more than a Subversion URL or a Maven POM in a manner of minutes. I'm frequently talking to companies interested in aligning internal development infrastructure with the tools and systems used in open-source software development. These organizations see developers participating in highly productive open source projects and they want to know what tools and what structures are required to bring this level of productivity to enterprise development. They are looking for a common development platform that provides tested patterns for collaboration and discourages each department from continuous wheel reinvention.
Eclipse and Maven are the platforms of choice, and closer integration between the two platforms will facilitate the continued adoption of Open Source tools and technologies in the enterprise. As more and more enterprises start to depend upon Maven for enterprise builds and Eclipse as a platform for development, more and more people will be looking to the m2e project to push the integration to the next level.
==================================================================================
Getting Started with m2e
Don't take my word for it; judge the m2e project by the software we've created. While there is still some integration left to make the combination of Maven and Eclipse perfect, the project is currently "shipping" a very capable Eclipse plugin. In the next section, I'm going to walk you through some of the more interesting and transformational features of the m2e project.
Installing m2e
To install m2e, open up Eclipse 3.4 (Ganymede). If you have yet to download and install Eclipse, you can get Eclipse 3.4 from http://www.eclipse.org. In Eclipse, select Software Updates... from the Help menu. In the "Software Updates and Add-ons" dialog, click on the Available Software button, and then click on Add Site.... Add the update site URL. Once you've added this URL to the update sites, you will be able to add Maven Integration, Maven Optional Components, and Maven Project Configurators to your project. If you are planning on using the Subclipse, Mylyn, and AspectJ integration in the m2eclipse plugin, you will need to also install these plugins. For a full set of instructions for installing the m2eclipse plugin, see the Eclipse chapter of Maven: The Definitive Guide. Downloading and installing the m2eclipse should take a few minutes, once the installation process is complete, Eclipse will recommend that you restart your IDE.
Once the installation process is completed, you'll be able to click around and explore m2eclipse. In the following sections, I'd like to walk you through some of the more interesting features in the m2eclipse plugin.
Creating a Maven Project from a Maven Archetype
A Maven archetype is a template for a new project, and the Maven repository contains many Archetypes for everything from web applications to messaging components. With m2eclipse, using a Maven Archetype is as easy as filling out a simple "New Maven Project" dialog and selecting an archetype from a list of all Maven Archetypes in the Central Maven Repository. If someone has published a Maven Archetype to a Maven repository, m2eclipse will locate this archetype when it queries the repository index. To create a Maven project using a Maven Archetype (see Figure 1), choose File → New → Project..., and then type in "maven" in the filter field. Select New Maven Project and click Next. The second screen of the New Maven Project provides an interface to select a Maven Archetype for your new project. There are many Maven Archetypes provided in the list that comes with m2eclipse.
The list of archetypes is generated by something called the Nexus Indexer. The Nexus indexer is a file that contains an index of the entire Maven repository. It is generated by the Nexus Repository Manager.
Materializing a Maven Project from a POM
m2eclipse also offers the ability to "materialize" a Maven project. Materialization is similar to the process of checking out a Maven project from Subversion, but instead of manually entering the URL to the project's Subversion repository, the Subversion URL is discovered from the project's root POM file. You can use this feature to "materialize" projects from nothing more than a POM file if the POM file has the appropriate elements to specify the location of a source repository. Using this feature, you can browse the central Maven repository for projects, and materialize them into Eclipse projects. This comes in handy if your project depends on a third-party open source library, and you need to get your hands on the source code. Instead of tracking down the project web site and figuring out how to check it out of Subversion, just use the m2eclipse project to magically "materialize" the Eclipse project.
Searching for Dependencies and Artifacts
The ability to quickly search and locate dependencies in a Maven repository is a tremendous time saver. With m2eclipse, you no longer need to hunt through the central Maven repository for an artifact version. If you need to add an artifact to a Maven project, right click on the project, and select Add Dependency under the Maven menu. Once you do this, you will see the dialog in Figure 2. Simply typing in a groupId or an artifactId causes m2eclipse to search a Nexus index of a Maven repository to display matching artifacts. The ability to quickly locate artifacts means that you will no longer need to spend countless hours clicking around the Maven repository just to find a particular artifact or dependency.
Analyzing Dependency Trees
M2eclipse provides some interesting features that allow you to analyze and graph your project's dependencies. You can load the POM Editor by clicking on your project's pom.xml file. If m2eclipse has been installed, you will see the POM Editor instead of the POM XML. If you open a project with many dependencies, you can open the Dependency Tree tab of the POM Editor and see a two-column display of dependencies as shown in Figure 3. The left-side of the panel displays a tree of dependencies. The first level of the tree consists of direct dependencies from your project, and each subsequent level lists the dependencies of each dependency. The left-hand side is a great way to figure out how a specific dependency made its way into your project's resolved dependencies. The right-hand side of this panel displays the resolved dependencies. This is the list of effective dependencies after all conflicts and scopes have been applied, and it is the effective list of dependencies that your project will use for compilation, testing, and packaging.
If you would rather view dependencies as a graph, click on the Dependency Graph tab to see a graph of your project's dependencies (see Figure 4). Click on a node in this graph to highlight that node and emphasize the relationships between that artifact and other artifacts in your project's dependencies.
Building Eclipse with Maven: Tycho
Like Eclipse's PDE, Tycho can build plugins and update sites for use with the Eclipse platform. Tycho can build Eclipse plugins using both pom.xml files and Eclipse's native metadata files such as manifest.mf and feature.xml. Tycho is part of a longer-term effort for Maven to build projects based on different kinds of project metadata. As of this writing, Tycho is being used to build Eclipse plugins for a few organizations and some open-source projects (including m2eclipse). Tycho is the most straightforward option for Eclipse developers looking to automate Eclipse plugin builds using Maven. The story for sharing binaries is less clear in the Eclipse world. There are Eclipse distributions, update sites, P2 repositories, web sites for dynamic provisioning, various proposals for OSGI repositories, and even some Eclipse bundles checked in to Maven repositories. Sonatype is committed to helping the Eclipse community create open and interoperable repositories and metadata that would be a benefit to all users, and Tycho is the first step toward making Maven and Eclipse interoperable.
Conclusion
It's hard to pick up new code: you have to find it and then figure out how to work with it. Nexus indexes make it easy to find artifacts, POM's make it easy to figure out and understand projects, and m2eclipse makes it easy to work with Maven projects in Eclipse. I believe the Eclipse world will learn some tricks from Maven and start to use Maven metadata and plugins. For people writing development tools, I believe a Maven mojo is the least amount of work required to write a tool and have it be usable not only in a command line build but also in Eclipse itself. I also believe many Eclipse plugins can use Maven POM information and dependency management for their own purposes. I look forward to the work, and invite everyone to pitch in and to enjoy the results. Just go to http://eclipse.org/m2e.
Resources
- The m2e Project
- The m2eclipse Plugin
- Nexus Repository Manager
- Sonatype
Published January 22, 2009 – Reads 4,304
Copyright © 2009 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.