If you're a user of Maven then you are familiar with the Project Object Model (POM) which is the basic unit of work in Maven. Maven is a project-centric tool and so we attempt to capture the essence of a project in the POM. This includes things like what your project is, where the project lives, where you can find the sources for project, who the developers are on the project and how you can get hold of them, what you need to build the project, the way your project will be built, what form your project will be distributed in, and where it will be distributed from.

But why would a project not using Maven care?

Whether you want to use Maven or not, users of your project - especially if you provide a framework or reusable library - may choose to use Maven. The quality of the metadata in the Maven repository is important to your users as they list dependencies on your metadata, and link in the information into their own projects.

Maintaining the metadata for your project is not hard - you can submit it to Maven at release time (and for large projects it can be setup automatically), and just need to describe your project, its location, version and most importantly dependencies. Not doing so, or providing incomplete or invalid information leaves this responsibility to the users of your project.

The Maven team does work on this metadata actively to improve its quality, but with thousands of artifacts in the repository and only a certain level of knowledge of other projects this is not ideal. Nobody knows your project better than you.

[top]

It is best to get it right at the time of a release to avoid having to make difficult updates later on. Your information can be submitted to Maven using the regular repository upload procedure.

The following information is what is best to provide:

• Project name
• Project URL
• License
• Description of the project
• Group and Artifact ID
• Packaging
• Version
• Dependencies

The group ID should resemble the package name, or reverse DNS of your web site, and can contain subgroups as you see fit: for example, org.apache.maven and org.apache.maven.plugins.

The artifact ID is specific to each artifact and by convention should be the filename, excluding extension.

The packaging is the type of your artifact, such as jar, war, ear, ejb, dll, etc.

Each dependency also contains their group ID and artifact ID, as well as version specification. In particular, you should ensure that optional dependencies are marked as such, and that runtime and testing only dependencies are marked with the given scope. Ranges can be used for version if that is appropriate, such as commons-collections [2.0,3.0). Ensure that the dependency exists in the Maven system and matches first.

See the format of the project descriptor for more information.

[top]

If you able to publish your releases to a Maven2 style repository and make it available over rsync, we can automatically publish them to ibiblio when released. This procedure requires that you take full responsibility for your metadata, but also ensures the best service for your users. If this is interesting to your project, contact dev@maven.apache.org.

[top]