content/fml/project-faq.fml

<?xml version="1.0" encoding="UTF-8"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one
  or more contributor license agreements.  See the NOTICE file
  distributed with this work for additional information
  regarding copyright ownership.  The ASF licenses this file
  to you under the Apache License, Version 2.0 (the
  "License"); you may not use this file except in compliance
  with the License.  You may obtain a copy of the License at

  http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing,
  software distributed under the License is distributed on an
  "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, either express or implied.  See the License for the
  specific language governing permissions and limitations
  under the License.
-->
<faqs xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://maven.apache.org/FML/1.0"
  xsi:schemaLocation="http://maven.apache.org/FML/1.0 http://maven.apache.org/xsd/fml-1.0.xsd"
  title="Frequently Asked Questions About Project Metadata">
  <part id="faq">
    <faq id="why-care">
      <question>Why do I care?</question>
      <answer>
        <p>
          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.
        </p>
        <p>
          But why would a project not using Maven care?
        </p>
        <p>
          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 <a href="/repository/">Central Maven repository</a>.
          The quality of the metadata in the Central Maven repository is important
          to your users, as they list dependencies on your metadata and link in the information into their own
          projects.
        </p>
        <p>
          Maintaining the metadata for your project is not hard - you can submit it to Central Maven repository 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 its dependencies. Not doing so, or providing incomplete or invalid information
          leaves this responsibility to the users of your project.
        </p>
        <p>
          The Maven team does <a href="/guides/mini/guide-maven-evangelism.html">work on this metadata actively to improve its quality</a>, 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.
        </p>
      </answer>
    </faq>
    <faq id="how-to-improve-metadata">
      <question>How do I make sure my project's dependency metadata is correct?</question>
      <answer>
        <p>
          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 Central Maven repository using the regular
          <a href="/guides/mini/guide-central-repository-upload.html">Central repository upload procedure</a>.
        </p>
        <p>
          The following information is what is best to provide:
        </p>
        <ul>
          <li>Project name</li>
          <li>Project URL</li>
          <li>License</li>
          <li>Description of the project</li>
          <li>Group and Artifact ID</li>
          <li>Packaging</li>
          <li>Version</li>
          <li>Dependencies</li>
        </ul>
        <p>
          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.
        </p>
        <p>
          The artifact ID is specific to each artifact and by convention should be the filename, excluding
          extension.
        </p>
        <p>
          The packaging is the type of your artifact, such as jar, war, ear, ejb, dll, etc.
        </p>
        <p>
          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.
        </p>
        <p>
          See the format of the
          <a href="/maven-model/maven.html">project descriptor</a>
          for more information.
        </p>
      </answer>
    </faq>
    <faq id="how-to-automatically-sync">
      <question>How do I ensure my latest releases automatically appear in the Central Maven repository?</question>
      <answer>
        <p>
          If you are 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.
        </p>
      </answer>
    </faq>
  </part>
</faqs>