Maven Repository

Guizhan Resources runs a read-only Maven repository for published project versions. If you develop against a project hosted here, you can pull it straight from Gradle or Maven instead of dropping JARs into a libs folder. Publishing is unchanged — releases still go through the normal project and automation workflows, and Maven clients cannot deploy to this repository.

If the developer runs their own Maven repository, use that one first. It may carry things this repository never will — sources and javadoc classifiers, snapshot builds, real POM metadata with transitive dependencies. Ours is the fallback that always exists, not necessarily the best source.

TL;DR

Add the repository, then depend on group:projectId:versionId:

repositories {
    maven {
        url = uri("https://resources.guizhanss.com/api/maven")
        content {
            includeGroup("com.guizhanss.resources")
        }
    }
}

dependencies {
    implementation("com.guizhanss.resources:PROJECT_ID:VERSION_ID")
}

Examples on this page use production. For staging, swap in com.guizhanss.resources.staging and https://staging.resources.guizhanss.com/api/maven.

Coordinates

Coordinate	Production	Staging
`groupId`	`com.guizhanss.resources`	`com.guizhanss.resources.staging`
`artifactId`	Project ID	Project ID
`version`	Version ID	Version ID
Repository URL	`https://resources.guizhanss.com/api/maven`	`https://staging.resources.guizhanss.com/api/maven`

Two things trip people up here. artifactId is the project ID, not the slug in the URL. And version is the version ID, not the display name or number you see on the site. You don’t have to remember either — open the version page and expand Use this version with Maven or Gradle to copy a ready-made snippet.

Adding the repository

Gradle

Keep the content { includeGroup(...) } filter from the TL;DR. Nothing outside com.guizhanss.resources will ever resolve from this repository, and with the filter Gradle won’t even ask it about your other dependencies — resolution stays fast.

Maven

With Maven, add the repository to a profile in ~/.m2/settings.xml:

<settings>
  <profiles>
    <profile>
      <id>guizhan-resources</id>
      <repositories>
        <repository>
          <id>guizhan-resources</id>
          <url>https://resources.guizhanss.com/api/maven</url>
          <releases>
            <enabled>true</enabled>
          </releases>
          <snapshots>
            <enabled>false</enabled>
          </snapshots>
        </repository>
      </repositories>
    </profile>
  </profiles>
  <activeProfiles>
    <activeProfile>guizhan-resources</activeProfile>
  </activeProfiles>
</settings>

Or declare it in the project POM instead:

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>example-app</artifactId>
  <version>1.0.0</version>

  <repositories>
    <repository>
      <id>guizhan-resources</id>
      <url>https://resources.guizhanss.com/api/maven</url>
      <releases>
        <enabled>true</enabled>
      </releases>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>

  <dependencies>
    <dependency>
      <groupId>com.guizhanss.resources</groupId>
      <artifactId>PROJECT_ID</artifactId>
      <version>VERSION_ID</version>
    </dependency>
  </dependencies>
</project>

Replace PROJECT_ID and VERSION_ID with the values from the version page snippet.

When a version is served

A version resolves only when all of these hold:

The owner (user or organization) has Maven enabled, and so does the project.
The project is approved and public.
The version has a primary file, and that file is a JAR uploaded to the platform — external URLs don’t count.

Miss any one of them and you get a plain 404. The repository deliberately doesn’t say which condition failed, so check the switches first (see below) before suspecting your build script.

What’s actually served: the primary JAR, a generated POM, maven-metadata.xml, an x-checksum-sha1 response header, and md5/sha1/sha256/sha512 checksum files. That’s all. No classifiers, no .module metadata, no AAR or WAR, no snapshot versions.

Caching, or “why am I still getting the old JAR”

Releases are meant to be immutable — one version ID, one file — but the platform currently lets an owner replace a version’s primary file. Treat that as a caveat, not a guarantee. Your build tool won’t notice a replaced file on its own, because Maven and Gradle both cache releases locally. If you suspect a stale artifact, rebuild with mvn -U or gradle --refresh-dependencies, or delete the cached copy by hand.

The same applies in the other direction. Deleting a version, or turning off a Maven switch, makes the repository return 404 — but a JAR that already reached someone’s machine stays there. Clients can also cache a 404 from before Maven was enabled, so if a freshly enabled version still fails, refresh again before reporting it.

For the curious: responses carry Cache-Control: no-cache, and the repository supports HEAD requests, ETag/If-None-Match conditional requests, and single-range downloads for resumable transfers.

The two Maven switches

Maven availability is controlled in two places:

The owner-wide switch, on the Maven settings page (/dashboard/maven for a user, or the organization’s settings page for an org).
A per-project switch, in the project list on that same page.

Projects default to on, but nothing is served while the owner-wide switch is off. Turning the owner switch off and back on doesn’t touch the per-project values — everything comes back exactly as it was. When a project changes hands, the new owner’s switches take over; the project ID and coordinates don’t change.

Rate limit

The repository allows 600 requests per minute per IP. Past that you get 429 with a Retry-After header — normal builds won’t come close, but a misbehaving CI loop might.

What counts as a download

Only successful JAR GET requests count, including range responses. HEAD, 304, POM and metadata fetches, checksums, 404, and 416 don’t. Repeated requests inside the analytics deduplication window may be merged into one.