Maven Tip: Project Directories Should Match the Artifact ID
I almost called this post a Maven “Pet Peeve”, but I’ll stick with “Tip” (and I’ll keep it brief). Here’s a new rule, and I’d really like to hear what the community thinks about this.
Here’s the rule:
Name your project’s directory after the artifactId of your project. It is much easier for everyone to quickly recognize and comprehend multi-module project structure, and it will more closely resemble the experience for developers working with IDEs.
Why do this?
Because it leads to simpler, easier to understand project structure. Some of you might be reading this and asking why we need to remind people of such an obvious rule. Others might take issue with the proposed rule, but I’ll try to detail why I think it is so important. Take the following collection of projects as an example:
Which one do you prefer? Left or right, and why?
On the one hand it is less typing for people on the command line to use simple directory names for Maven modules.
But, on the other hand, if you import these projects with m2eclipse you are going to end up with projects named after the artifactId. The same is true if you import these projects into IntelliJ.
I would suggest always opting for the option on the right. It is clearer than the alternative, and requires less hands-on investigation to track down a culprit project if you are debugging build errors.
An Important Note from Brian Fox: Naming the folder after the artifactId is critical if you expect inherited urls (scm/site) to work. It always appends the artifactId to the url as it’s inherited. And for the same reason, you want them to match what’s in the scm.
Using the Maven Release plugin: Things to know
When should the code be tagged? How is the release/branch/tag process related to deployment? How should we branch during the release process? Should we branch early on in the release? Or, should we just continue on in trunk and only branch when we need to start parallel development? Who performs the release and from what machine? Do we run this plugin from Hudson?
This is a sample of some of the questions I’ve been asked by customers over the past few years, and, believe it or not, my answers are always a little less than satisfying. My stock answer to one of these questions is along the lines of: Well, Maven has a certain set of opinions about how you should manage releases, but it isn’t set in stone and there are as many variations in a project’s release process as there are corporations that code Java.
What we call “The Release Process” is seldom simply a technology problem and more than often involves process, organizational structure, and definitions of responsibilities. These are the intangibles that lead to the reality: everyone’s “Release Process” tends to be unique, especially as your projects become more important and more complex.
How to build a RAP application with Tycho
Holger Staudacher, at EclipseSource, has a good writeup of his experience evaluating Tycho for the Runtime Packaging Project (RTP). Here’s an excerpt of what he has to say:
Recently I played around a little with Tycho because we evaluated it for the use in the RTP project. As a test case, I decided to try to build a RAP application with Tycho. With building I mean compiling and packaging the artifacts into a WAR file in order to deploy them on a Tomcat or another Servlet Container. I have to say that I’m really impressed with Tycho. Before this experience…
It’s great to see different projects trying Tycho at the Eclipse Foundation: having standard recipes for building RAP applications would be extremely useful addition for the community. RAP is not something that Sonatype is directly involved with so it’s great to get this varied perspective, and different applications types so we can make sure Tycho will work for as many use cases as possible. Thanks Holger!
Holger has some good examples at Github, and you can find his original blog entry here.
We are currently working on submitting the CQs for Tycho so we can move the project over to the Eclipse Foundation. I think Wayne Beaton said he wanted to help with those CQs. Right Wayne? 
Maven How-To: Merging Plugin Configuration in Complex Projects
In projects with many parent POMs, profiles, and plugin management sections, one can easily end up in a situation where the effective configuration for a plugin is the result of merging many configuration blocks from the various POM sources together.
Not knowing the details of this merge process naturally leads to some confusion about why an effective configuration looks the way it looks, or why changes to some parent POM’s configuration don’t have the desired effects in child POMs.
This post attempts to shed some light on this confusion, and provides you with a sense of how Maven merges plugin configuration from multiple sources. This post uses attributes which are available in Maven 3.0.2.
Maven IDE: The year of Maven & Eclipse
There are many things we would like to see accomplished in the Apache Maven ecosystem in 2011 but one of the most important, we feel, is the sound integration of Maven with Eclipse. A great deal of effort was spent bringing Maven 3.x up to the level where it can be leveraged for an effective integration with Eclipse. With Maven 3.0 released in 2010 we are in a position to focus on the Eclipse side of the equation. For those you who watch the M2Eclipse JIRA you can see a great deal of activity and that’s because Sonatype’s M2Eclipse team is doing for M2Eclipse what Sonatype’s Maven team did for Maven 3.0. Sonatype is working on the internal architecture of M2Eclipse, adding tests, and preparing the path forward which means the integration of Maven with the rest of the Eclipse ecosystem.
Sonatype is investing heavily to ensure the baseline M2Eclipse 1.0 is of high quality, stable, and maintainable. With the help of the amazing IP team at the Eclipse Foundation M2Eclipse has passed its initial IP review, has entered the parallel IP process and is slated to be released as part of the 2011 Indigo release of Eclipse. To be certain, this will be a great milestone for the Maven and Eclipse ecosystems: users have been asking for years to have good Maven integration included in the standard Eclipse distributions and this will be the year they get it. Indigo will ship this year on June 22nd, but in the meantime Sonatype will be working on and soon releasing Maven IDE!
What is Maven IDE exactly? Maven IDE is a Maven-focused distribution of Eclipse that will consist of a base Eclipse distribution, M2Eclipse and a series of Maven-focused integrations where there is strong support within the Maven and Eclipse ecosystems. What are some of the things we are looking at potentially integrating?
Frameworks and languages
JSR-330 & Guice integration: JSR-330 & Guice are now critical to the Maven ecosystem and very important to Sonatype as a technology. The JSR-330 implementation provided by Guice provides core functionality for Maven 3.x, Nexus, M2Eclipse, and Sonatype’s Maven 3.x integration for Hudson. We will create tooling for JSR-330 to help with our own work, general integration work for development infrastructures, and anyone using JSR-330.
Webapp development tooling: Webapp development is the most requested form of integration and we are still evaluating what’s available in WTP versus making something that is simpler and integrates more tightly with Maven. For those that don’t know, the WTP integration for M2Eclipse is not part of the codebase that moved to Eclipse. Sonatype will be working with the community on the M2Eclipse/WTP integration and will help distribute it from Sonatype, but we are also looking at alternatives to WTP.
Tycho integration: We already have support for Tycho inside Eclipse that allows Tycho projects to interoperate with PDE at a rudimentary level, but we would like to improve this integration and bring support for Tycho-based projects into the Eclipse IDE.
Maven Shell integration: This is where the Maven command line will intersect with the IDE. We see in the future being JSR-330 component based so we can leverage them from the Maven Shell and Maven IDE, and these components will participate in long-lived workflows that aid in the development of applications. We plan to use Drools Flow for the workflow implementation and the Eclipse tooling that exists for Drools Flow. The workflows will be accessible and usable from the Maven Shell as well as from within Maven IDE.
Polyglot Maven integration: For some of the selected grammars and dialects of Polyglot Maven we will provide support in Maven IDE. The folks at Itemis have been a great in helping us understand how Xtext can play a critical role in this regard. If a grammar can be represented in a form that Xtext understands then much of the plumbing for powerful editors can be created automatically using the Xtext framework. There are currently some integration issues between standard Maven and OSGi that need to be resolved but Xtext is an incredibly powerful language workbench. The Itemis guys have really done some incredible work.
Android development tooling: Android is becoming very popular and has a strong Maven contingent. There are sophisticated Maven-based tools for developing Android apps that have been created by Android community: the maven-android-plugin by Hugo Josefson from Jayway, the Eclipse integration exists as part of what Google provides, and Ricardo Gladwell has created the bridge between Maven and Eclipse with his Android M2Eclipse integration.
Scala IDE: Miles Sabin is creating great Eclipse integration for Scala with his Scala IDE project and David Bernard is bridging that work into Maven m2eclipse-scala. We are seeing a lot of demand for Scala integration with Maven.
GWT integration: GWT has rapidly become one of the standard webapp toolkits for Java and we’ve seen a lot of demand for better integration with M2Eclipse. Within the realm of development infrastructure GWT is very popular. Sonar uses GWT, Gerrit uses GWT, XWiki uses GWT, and Sonatype has chosen GWT as the basis of the UI for our Maven 3.x integration in Hudson. GWT will continue to gain momentum so it’s very likely we will have more sophisticated integration with M2Eclipse sooner rather then later.
Development infrastructure
Sonar integration: Sonar is becoming the de facto standard reporting and quality system for Java projects. Sonar is very Maven-centric and SonarSource has provided Eclipse integration that can easily be integrated with Maven IDE.
Hudson integration: Hudson is the de facto standard continuous integration server for Java projects. Sonatype is currently working on finishing our Maven 3.x integration and it will be integrated within Maven IDE.
Wiki editing & site publishing: Sonatype has a wiki page editing and publishing framework called Idiom — that is based on the WikiModel project — that we will be open sourcing, and hopefully merging with the tools that exist in the WikiText project at Eclipse. Ultimately we would like to see WikiModel merged with WikiText and then work together within the community to make great editing tools. If WikiModel could be wed with Xtext it would be amazing.
SVN integration: Obviously important and we initially removed the SVN support to clean up and focus on the core. We’re layering it back in as resources permit. It’s not going anywhere and there are actually two options now. Sonatype supports the Subversive integration which is the official SVN integration at Eclipse, but the community has contributed the Subclipse support. So both variants will be available and Maven IDE will ship with the Java-based SVNKit connector.
Git integration: Git is sweeping over the development community and has taken off like wildfire. At Sonatype we use Git for the vast majority of our projects so great Git integration with Eclilpse and Maven is vital.
Maven Central statistics and metadata: Many OSS projects have been thrilled with the statistics we’ve provided them and we’ll be working in the future to provide more value from the information in Maven Central and deliver it into Maven IDE. Maven Central is an unparalleled source of interesting and useful information for developers and we want to make all that information more accessible.
So you can see that the number of paths we can potentially take are limitless. What will really help us limit our choices are the partners we find who are as committed as we are to the Maven and Eclipse ecosystems. We’re not interested in individuals, groups, or organizations that are hedging their bets with Maven and Eclipse. We are looking for individuals, groups, and organizations who are committed to the Eclipse Platform and Maven as the basis of their development infrastructures.
Things we’ll be looking for in integration partners, are: Tycho build, good test infrastructure, and a composite p2 repository for integration. Maven IDE will first be available in an OSS community edition and will be followed by future commercial versions. We are excited about building out a polished, Maven-focused distribution of Eclipse and we’re really looking for feedback from the community about what integrations to pursue first. So please let us know!
Apache and Apache Maven are trademarks of the Apache Software Foundation. Maven Central is a service mark of Sonatype, Inc. Nexus, Maven IDE, Maven Shell, and Polyglot Maven are trademarks of Sonatype, Inc. Maven Central, Maven IDE, Maven Shell, and Polyglot Maven are intended to complement Apache Maven and should not be confused with Apache Maven.
