This chapter describes how to publish build artifacts to an Apache Maven Repository.
A module published to a Maven repository can be consumed by Maven, Gradle (see Chapter 51, Dependency Management) and other tools that understand the Maven repository format.

66.1. The “maven-publish” Plugin

The ability to publish in the Maven format is provided by the “maven-publish” plugin.

The “publishing” plugin creates an extension on the project named “publishing” of type PublishingExtension.
This extension provides a container of named publications and a container of named repositories. The “maven-publish” plugin works with
MavenPublication publications and MavenArtifactRepository repositories.

66.2. Publications

If you are not familiar with project artifacts and configurations, you should read the Chapter 52, Publishing artifacts
that introduces these concepts. This chapter also describes “publishing artifacts” using a different mechanism than what is
described in this chapter. The publishing functionality described here will eventually supersede that functionality.

Publication objects describe the structure/configuration of a publication to be created. Publications are published to repositories via tasks, and the
configuration of the publication object determines exactly what is published. All of the publications of a project are defined in the
PublishingExtension.getPublications() container. Each publication has a unique name within the project.

For the “maven-publish” plugin to have any effect, a MavenPublication must be added to the set of publications.
This publication determines which artifacts are actually published as well as the details included in the associated POM file.
A publication can be configured by adding components, customizing artifacts, and by modifying the generated POM file directly.

66.2.1. Publishing a Software Component

The simplest way to publish a Gradle project to a Maven repository is to specify a SoftwareComponent to publish.
The components presently available for publication are:

66.2.2. Publishing custom artifacts

It is also possible to explicitly configure artifacts to be included in the publication. Artifacts are commonly supplied as raw files, or as instances of
AbstractArchiveTask (e.g. Jar, Zip).

For each custom artifact, it is possible to specify the extension and classifier values to use for publication. Note that
only one of the published artifacts can have an empty classifier, and all other artifacts must have a unique classifier/extension combination.

Certain repositories will not be able to handle all supported characters.
For example, the ':' character cannot be used as an identifier when publishing to a filesystem-backed repository on Windows.

Maven restricts 'groupId' and 'artifactId' to a limited character set ([A-Za-z0-9_\\-.]+) and Gradle enforces this restriction.
For 'version' (as well as artifact 'extension' and 'classifier'), Gradle will handle any valid Unicode character.

The only Unicode values that are explicitly prohibited are '\', '/' and any ISO control character.
Supplied values are validated early in publication.

66.2.4. Modifying the generated POM

The generated POM file may need to be tweaked before publishing. The “maven-publish”
plugin provides a hook to allow such modification.

In this example we are adding a 'description' element for the generated POM. With this hook, you can modify any aspect of the POM.
For example, you could replace the version range for a dependency with the actual version used to produce the build.

It is possible to modify virtually any aspect of the created POM should you need to.
This means that it is also possible to modify the POM in such a way that it is no longer a valid
Maven Pom, so care must be taken when using this feature.

The identifier (groupId, artifactId, version) of the published module is an exception; these values cannot be modified in the POM using the `withXML` hook.

66.2.5. Publishing multiple modules

Sometimes it's useful to publish multiple modules from your Gradle build, without creating a separate Gradle subproject.
An example is publishing a separate API and implementation jar for your library. With Gradle this is simple:

The DSL used to declare repositories for publication is the same DSL that is used to declare repositories to consume dependencies from,
RepositoryHandler. However, in the context of Maven publication only
MavenArtifactRepository repositories can be used for publication.

In this example, a task named “publishMavenJavaPublicationToMavenRepository” is created, which is of type
PublishToMavenRepository.
This task is wired into the publish lifecycle task.
Executing “gradle publish” builds the POM file and all of the artifacts to be published, and transfers them to the repository.

66.5. Publishing to Maven Local

For integration with a local Maven installation, it is sometimes useful to publish the module into the local .m2 repository. In Maven parlance, this is
referred to as 'installing' the module. The “maven-publish” plugin makes this easy to do by automatically creating a
PublishToMavenLocal task for each MavenPublication
in the publishing.publications container. Each of these tasks is wired into the publishToMavenLocal lifecycle task.
You do not need to have `mavenLocal` in your `publishing.repositories` section.

The resulting task in this example is named “publishMavenJavaPublicationToMavenLocal”. This task is wired into the publishToMavenLocal lifecycle task.
Executing “gradle publishToMavenLocal” builds the POM file and all of the artifacts to be published, and “installs” them into the local Maven repository.

66.6. Generating the POM file without publishing

At times it is useful to generate a Maven POM file for a module without actually publishing. Since POM generation is performed by a separate task, it is very easy
to do so.

The task for generating the POM file is of type GenerateMavenPom, and it is given a name based on the name
of the publication: “generatePomFileFor«PUBNAME»Publication”. So in the example below,
where the publication is named “mavenCustom”,
the task will be named “generatePomFileForMavenCustomPublication”.

All details of the publishing model are still considered in POM generation, including components`, custom artifacts,
and any modifications made via pom.withXml.

The “maven-publish” plugin leverages some experimental support for late plugin configuration,
and any GenerateMavenPom tasks will not be constructed until the publishing extension is configured.
The simplest way to ensure that the publishing plugin is configured when you attempt to access the GenerateMavenPom task
is to place the access inside a model block, as the example above demonstrates.

The same applies to any attempt to access publication-specific tasks like PublishToMavenRepository.
These tasks should be referenced from within a model block.