Archetypes: New in Nexus OSS and When to Use Archetypes

How do you start a new Maven project? Many of us resort to a copy and paste approach to a new project. If you need another project: create a new directory, copy the POM file from a similar project, customize it. If I were the lecturing type, this is when I'd put down the chalk, turn to the class and give a solemn lecture about how copy and paste programming will earn you a failing grade in my class. I've had enough real-world consulting experience to know that working "reality" for programmers isn't pretty. We do what we need to do to get things done, and elegance and efficiency are not always the primary concerns (especially for a software build).

In this post, I'm going to talk about some recent changes to Nexus that will help you distribute Maven Archetypes, and I'm also going to offer some strategies for when you should start to think about using Maven Archetypes to support development.

Distributing Maven Archetypes with Nexus

While Maven Archetypes provide a clean way to create a new project, I fully understand and accept that many of us copy, paste, and modify existing POMs into new Maven projects. The issue with Archetypes up until this point has been one of distribution. Once you create a Maven Archetype, how do you publicize it? For years, there was no great answer to this question, you had to tell people about an explicit set of coordinates and you also had to tell people to run a long, ugly looking command-line.

A few years ago, Sonatype created the Nexus Indexer and now users have a much easier way to list available archetypes. If your Archetype ends up on Maven Central, it will eventually make its way into the list of available archetypes in m2eclipse or when you run the Archetype generate goal. Instead of telling people to execute a difficult, longish command line, just tell them to fire up m2eclipse and search for the archetype by groupId or artifactId.

What about internal archetypes on your own repository? The latest version of Nexus OSS has a solution for that? We've added the Nexus Archetype plugin as a core plugin. This means that you can start to benefit from the same distribution mechanism for your own, internal archetypes. If you use an internal Nexus repository, you can point your Maven clients and m2eclipse IDEs to this instance and see a catalog of Archetypes which will include your own archetypes.

When to Use a Maven Archetype?

Open source projects and libraries.

Using a Maven Archetype you can capture the skeleton of a project and include some sample code that can be customized. If you are creating some open source framework, say a web framework, or a new way to interact with a database, you should be publishing a set of Maven Archetypes. Projects (and companies) can reduce the amount of effort needed to integrate technologies by publishing archetypes to Central. If you need to create a plugin for Confluence or JIRA, it is easy, just use the JIRA plugin archetype. Need to write an AppFuse application, don't invest a few hours figuring out what dependencies you need and what the suggested project structure is, take a short cut and fire up an AppFuse archetype.

While some projects realize this, I still think there is a lot of unclaimed territory. Some examples that stand out are the myriad of NoSQL products with Java APIs. A project like MongoDB would bring itself much closer to the developer audience by publishing ready-made Archetypes to central. I could list out a hundred more projects that would see more wider adoption with a Maven Archetype, and I've made it one of my own goals to try to get more projects to see Maven Archetypes as an essential part of developer community support.

When to Use Archetypes for Internal Projects

For internal projects, the value of using a Maven Archetype is up for some debate. For example, if you are working on a collection of web applications and you need to create a new one, you have two choices. You can:

• Copy the existing project to a new directory, change some identifiers and modify your code appropriately. This option is entirely acceptable for a medium-sized workgroup. If you are working on a manageable piece of code, creating a Maven Archetype just to save a few minutes of duplication and effort makes little sense. It is OK to copy, paste, customize sometimes and you shouldn't view Maven Archetypes as a requirement if you have a few projects that duplicate structure and POM configuration.
• Create a new Maven Archetype which captures the core structure and configuration of your project and just seed a new project from this archetype. If you work on a library or framework that has internal customers. For example, if you work on a web frameworks group on a larger project and your internal "clients" are creating new projects, you will certainly want to think about creating a set of internal Archetypes.

Clearly there is a time to use archetypes and a time to just copy and paste projects. If you are only creating a handful of projects over the course of a multi-year project, then you might just opt for the simple copy and paste approach to project expansion. If your project frequently creates new projects, and if these projects all have a common structure, you will likely want to create a new Archetype to capture the common pattern.

In Organizations "of Scale" Archetypes are Essential

Sonatype very frequently talks to organizations that program systems on a world-wide scale. Large banks with thousands of developers all working within a common framework developed by an architecture group. In these situations, internal archetypes don't just make sense, they become a necessary part of doing business. When you have multiple departments creating new architectures, sharing code, and creating APIs for one another, you will need to define structures and standards for projects and builds.

Why? The most common inefficiency we've seen is an organization that lacks strict standards for project builds. We're not just talking about POM structure here, we're talking about the organization that has ten critical subsystems managed by separate teams each with an individual idea of what the build is for. One team uses Ant, another uses Maven, and yet other teams decide to create custom frameworks.

If your organization has problems integrating multiple, disparate builds into a single working system, you probably need to start thinking about standardization. While Maven provides a baseline of standardization in the form of POM structure, dependencies, artifact coordinates, and repository management, defining a set of Maven Archetypes as "enterprise templates" will help to define how projects are created and managed.

In summary, Maven Archetypes are more than just simple example templates to be used with open source projects. You can leverage the power of Maven Archetypes for your own, internal development, and you can use the newly release Nexus OSS to make it even easier to distribute these templates to your own internal users.