repo.mcmiddleearth.com is MCME's own Maven repository. MCME's libraries and plugins publish their release jars there, and every MCME build resolves its MCME dependencies from it. It also keeps a cached copy of the outside repositories our builds use, so a build keeps working when one of them is down. Reading is open to everyone, with no account; publishing needs a token. The server runs Reposilite; how it is run is in CI/CD (operators only).

The three repositories

The mirror never fetches com.mcmiddleearth artifacts from outside. MCME artifacts come only from releases and snapshots.

Using it in a build

Maven

<repositories>
    <repository>
        <id>mcme-releases</id>
        <url>https://repo.mcmiddleearth.com/releases</url>
        <snapshots><enabled>false</enabled></snapshots>
    </repository>
    <repository>
        <id>mcme-snapshots</id>
        <url>https://repo.mcmiddleearth.com/snapshots</url>
        <releases><enabled>false</enabled></releases>
    </repository>
    <repository>
        <id>mcme-mirror</id>
        <url>https://repo.mcmiddleearth.com/mirror</url>
    </repository>
    <!-- Upstream fallbacks you still want, after the mirror -->
    <repository>
        <id>papermc</id>
        <url>https://repo.papermc.io/repository/maven-public/</url>
    </repository>
</repositories>

List mcme-mirror before any upstream repository you keep as a fallback. Maven tries repositories in order, so an artifact the mirror already has is served without touching the upstream. MCME-Connect's pom.xml is a complete example.

Gradle

Kotlin DSL (build.gradle.kts):

repositories {
    maven("https://repo.mcmiddleearth.com/releases")
    maven("https://repo.mcmiddleearth.com/snapshots")   // only if you use a -SNAPSHOT
    maven("https://repo.mcmiddleearth.com/mirror")
    mavenCentral()
    maven("https://repo.papermc.io/repository/maven-public/")
}

Groovy DSL (build.gradle):

repositories {
    maven { url = 'https://repo.mcmiddleearth.com/releases' }
}

Then depend on an artifact as usual, for example compileOnly("com.mcmiddleearth:PluginUtils:2.0.6"). MCME libraries and plugins are installed on the servers as plugins of their own, so the scope is provided (Maven) or compileOnly (Gradle).

What is published

Checked on 2026-11-02 against each artifact's maven-metadata.xml.

To see the current list for one artifact, open its metadata, for example https://repo.mcmiddleearth.com/releases/com/mcmiddleearth/PluginUtils/maven-metadata.xml.

Rules worth knowing

• One coordinate per library. Use com.mcmiddleearth:PluginUtils, not JitPack's com.github.MCME:PluginUtils. Build tools treat different group ids as different libraries, so a build that gets both ends up with two copies and no version resolution between them.
• Releases are final. Publishing a version that already exists fails with 409 Conflict. Release the next version instead.
• PluginUtils 1.9.x comes with its original POMs, which name a dependency on a local server jar. Maven warns about an invalid POM; the jar itself resolves. No current plugin uses 1.9.x.

Publishing

Publishing is for artifacts other MCME code compiles against (the two libraries and the plugins other plugins build on), and for plugins whose release jars should be available from one checked place. Writing needs a token from the MCME operators. Tokens can write only under com/mcmiddleearth/.

From a Maven project

Point distributionManagement at the repository, with the server id mcme:

<distributionManagement>
    <repository>
        <id>mcme</id>
        <url>https://repo.mcmiddleearth.com/releases</url>
    </repository>
    <snapshotRepository>
        <id>mcme</id>
        <url>https://repo.mcmiddleearth.com/snapshots</url>
    </snapshotRepository>
</distributionManagement>

The credentials never go in the pom. Locally they go in ~/.m2/settings.xml:

<settings>
  <servers>
    <server>
      <id>mcme</id>
      <username>token-name</username>
      <password>token-secret</password>
    </server>
  </servers>
</settings>

From a Gradle project

PluginUtils and Guidebook read the credentials from two environment variables, MCME_MAVEN_NAME and MCME_MAVEN_SECRET, and choose snapshots or releases from the version suffix. See PluginUtils' build.gradle (the publishing block). Without the variables, publish fails and every other task works as usual.

From GitHub Actions

MCME's workflows publish a release only from a release tag or a manual run, never from an ordinary push. (MCME-Base also publishes a -SNAPSHOT on every push to its development branch.)

• Maven: actions/setup-java writes the settings.xml entry when given server-id: mcme, server-username: MCME_MAVEN_NAME and server-password: MCME_MAVEN_SECRET; the deploy step sets those two environment variables from the repository's secrets of the same names.
• Gradle: the publish step sets the same two environment variables from the secrets.
• Check before you deploy. Because releases refuses a second upload, the workflows check that the tag matches the version (and, in several, that the changelog has a section for it) before the deploy step, so a failed check never leaves a half-published release.
• Secrets have to reach the repository. The two secrets are organisation secrets shared with selected repositories only. A workflow in a repository that has not been granted them gets empty values, and the deploy fails with 401 Unauthorized. Ask an organisation admin to add the repository when you add a publish step.
• Private repositories get their own token. On GitHub Free, organisation secrets don't reach private repositories, or personal ones. Such a repository gets its own token from the MCME operators, limited to its own artifact and stored in its repository secrets under the same two names, so the workflow doesn't change. Anyone can download what is published here, so a private repository should not publish a sources jar, and a jar that has to stay private stays on its repository's GitHub Releases instead.

Reference workflows: MCME-Base build.yml (Maven, snapshots from development, releases from v* tags), PluginUtils build.yml (Gradle) and TheGaffer build.yml (a multi-module build that deploys all modules at the end, so a failing module publishes nothing).

Troubleshooting