Sonatype Blog

Another minor release of Maven: The Definitive Guide. This update changes some screenshots in the m2eclipse chapter, and it also adds a section about the Goal selection dialog.

Uncategorized

I’ve released another version of the Maven Book today. The PDF version is back by popular demand (weighing in about 550 pages), and the Eclipse chapter has been updated. Also, some tweaks to the HTML formatting.

Nothing major, but I’m trying to consistently announce any changes no matter how substantial on this blog because there seems to be a loyal following of RSS subscribers (sorry ATOM, RSS is the legacy feed format). Again, thanks for *Everyone* who has emailed me with feedback and who has identified typos and errors.

If anyone has any feedback on the format and presentation of the HTML version, please let me know. Questions I’m asking you (the audience) are:

• Do you want a different HTML chunking option? Does one long document for every chapter work? Would you like more granular chunking?
• How about the PDF? Would you like to be able to download individual chapter PDFs?
• Is anyone out there clamoring for another ebook format?

Uncategorized

I answer this question often enough that I decided to burn it to a blog so I don’t have to dig it out of the source anymore…and maybe save someone else the time along the way.

Here is the relevant code that Maven uses to determine if an artifact is a snapshot or not:

String LATEST_VERSION = "LATEST";
String SNAPSHOT_VERSION = "SNAPSHOT";
Pattern VERSION_FILE_PATTERN = Pattern.compile(
 "^(.*)-([0-9]{8}.[0-9]{6})-([0-9]+)$" );
public boolean isSnapshot()
{
     if ( version != null || baseVersion != null )
     {
       Matcher m = VERSION_FILE_PATTERN.matcher( getBaseVersion() );
       if ( m.matches() )
       {
          setBaseVersion( m.group( 1 ) + "-" + SNAPSHOT_VERSION );
          return true;
       }
       else
       {
         return getBaseVersion().endsWith( SNAPSHOT_VERSION ) ||
         getBaseVersion().equals( LATEST_VERSION );
       }
     }
     else
     {
       return false;
     }
  }

Essentially this code is checking if the version ends with SNAPSHOT or if the pattern matches a timestamped version such as “2.0.10-20080415.233129-15″.

How-To, Maven

Gaining a larger user base is usually a goal of most OSS projects and obviously making it easier for users to get and user your project will help to grow that base. That’s why I was disappointed to see the following statement from a fellow OSS developer in response to the donation of a pom to get a new artifact added to the repo: “That’s great and all, but I don’t really care about Maven, nor do I really want to add or maintain a pom.xml in the project. Sorry.” Disclaimer: I’ve never used this project, nor do I know any of the developers, but the statement stands for itself.

The Maven Central repository is a great resource to the community. The artifacts contained here represent a vast variety of open source projects. Having the artifacts here not only enables easy consumption by Maven users, but even Ant users via Ivy. Beyond the jars themselves, complete poms can be a wealth of information for users, such as where the source is located, mailing lists, which license is used, etc. Often the source and javadocs are packaged up for easy development in IDEs

There is some work occurring to abstract the artifact, metadata and transport of artifacts to enable easy consumption by other tools. The intent of the maven-artifact-3.0 project is to provide a simple set of APIs that can operate against the repository data for dependency analysis and retrieval. The framework is being designed to allow pluggable rules to extend and support the various concepts in use out there such as Maven, OSGI and Ivy. All this is being done in a way to keep it fully decoupled from the Maven core code.

In summary, the Central repository is a resource that enables greater distribution and consumption of your project by many types of users. The desire make life easier for your users should transcend your personal views on any particular tool.

The Maven project does have a mechanism for taking community created poms (although we prefer they come from the project itself). If you run into a wall with some project and that isn’t enough to cause you to choose another implementation, then you can read more about how to get said walled project into the repository here.
Making it easier to get things into the Central repository is something we have been looking in to. We have some ideas, but the first step is working through the MEV list and we have recently started doing just that.

Maven

Maven has two sections in the pom relating to plugin configuration: project.build.plugins and project.build.pluginManagment.plugins. These two sections are unfortunately often confused and misused.

PluginManagement is similar to dependencyManagment in that it provides configuration and defaults for plugins if they are used in the build. This is where we recommend you lock down your plugin versions, but it also allows default configuration.

The regular plugins section also allows the version and default configuration to be defined, and this is where the confusion lies. It is technically valid to define the plugin version and default configuration here, but I find it easier to grok the pom when following this guideline:

• If the plugin block is not defining an execution (and thus binding maven to do something in the lifecycle), put that block in pluginManagment

This means that configuration for plugins brought in by the default lifecycle such as resources, compiler, jar, etc will almost always go in the pluginManagement section. Doing so tends to keep your regular plugins section rather small and only showing the config for plugins that are doing additional things during the lifecycle.

Following the above defined guideline will also have you locating the config for plugins that are primarily run from the command line in pluginManagment…again keeping the plugins section clean and concise.

How-To, Maven

Occasionally you have a need to add additional source folders to your Maven build, usually when you are generating source via some external method or AntTask. Maven plugins that generate sources are expected to add the source folder automatically, but that’s of little consequence if your generation method is not supported by an existing Maven plugin. Fortunately, there is the build-helper-maven-plugin to assist you. The usage page gives plenty of examples. Adding an additional source folder is as simple as:

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.1</version>
        <executions>
          <execution>
            <id>add-source</id>
            <phase>generate-sources</phase>
            <goals>
              <goal>add-source</goal>
            </goals>
            <configuration>
              <sources>
                <source>some directory</source>
                ...
              </sources>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Several threads cited from Inderjeet’s blog suggest tweaking the compiler plugin’s includes settings to add the additional source folder. While this will work in simple cases, this method does not actually add an additional sourceFolder element in the project model. This means other plugins, particularly IDE integrations such as M2eclipse won’t see these folders and will cause you trouble down the road. We therefore suggest that you use the build-helper instead.

The build-helper lets you do some other handy things such as attach additional artifacts (attachedArtifacts), purge the project’s artifacts from the local repository and add additional testSource folders.  

How-To, Maven

m2eclipse is more than just a simple plugin, it changes the way you’ll create projects. Specifically, it will allow you to create projects from archetypes without having to type a command-line the size of a paragraph. I just updated the m2eclipse chapter and included more details about the 88 available archetypes in the Maven repository.

On deck for the book is information about the POM editor…

The following is an excerpt from the chapter. What is interesting about the m2eclipse plugin is that it has the side-effect of making it easier to adopt the projects that have created Maven Archetypes. Granted, this project list could be larger, but it should be interesting to someone who wants to get a quickstart into developing an application with Wicket or AppFuse. The other thing that is very cool about m2eclipse is that it doesn’t ship with a static list of archetypes, m2eclipse is using the Nexus Indexer to maintain an index of the Maven repository.

When this chapter was last updated, m2eclipse had approximately ninety archetypes in this Archetype dialog. Highlights of this list include:

^[4]And these were just the archetypes that were listed under the Nexus Indexer Catalog, if you switch Catalogs you’ll see other archetypes. While your results may vary, the following additional archetypes were available in the Internal Catalog:

Book, m2eclipse

Geertjan posted a blog post about Netbeans and the wide array of Maven Archetypes this morning, I posted an almost identical post from an Eclipse perspective. This was an entirely unplanned coincidence, but it is a synchronicity that tells me that the usefulness of the archetype plugin is upon us, and that it is triggered by IDE integration.

If you are not already a subscriber to Geertjan’s blog, you should subscribe. He’s a great communicator, and also very much of the cooperative, open source ethos. Even though we’re focused on Eclipse integration at the moment, I get the sense that Netbeans has really started to become an attractive development platform (especially for JRuby). If you think we shuld pay more attention to the Maven Netbeans integration feel free to let us know by leaving a comment on this blog.

Uncategorized

When responding to questions on IRC, the Maven Users list, or giving Maven Training, I frequently run into misused terms of the Maven lingo. Here’s an attempt to define them “for the record”:

Reactor

Siblings

Parent Pom

Corporate Pom

Super Pom

Artifact

Dependency

Attached Artifact

Classifier

Our book shows all these elements and more in action.

How-To, Maven

All Nexus functionality is exposed via a RESTful API, the details of this API have been published. This is a work in progress as we continue to add new functionality, but these pages are regularly updated as part of our development process.

Also posted is our up to date product roadmap.

If you have ideas or want to get something added to the map, please join us at #nexus on irc.codehaus.org or Subscribe to our user list and report an issue to our Jira.

How-To, Maven, Nexus