Creating a free private maven artifact repository in seconds

OCT 3, 2025 — 4 minutes

With Repsy you can easily create a free private Maven repository in seconds. Without any installation or any hosting cost. Literally just within seconds you have your own Maven repository.

Creating a free private maven artifact repository in seconds

DRY: Don’t Repeat Yourself (Unless You’re Telling a Great Joke)

Most developers know the golden rule: DRY—Don’t Repeat Yourself. It’s the sacred mantra whispered in code reviews and etched into the minds of those who’ve reached a certain level of seniority… or mastered the art of smart laziness.

At some point, we all start crafting reusable bits of brilliance—components, packages, libraries, artifacts. The names vary wildly, from the sprawling jungles of frameworks to the steep cliffs of programming languages. But the mindset? Always the same: don’t repeat yourself.

Since this post is firmly planted in the Java ecosystem, let’s talk software packages—specifically, Maven artifacts. Apache Maven burst onto the scene in 2004, back when some of today’s developers were still mastering the art of walking. It flipped the script with a new directory structure, a magical pom.xml file, and the ability to create submodules like a wizard conjuring spells.

Then came the Maven repository—aka the Maven artifact repository. Think of it as a central treasure trove where your software packages (JARs, WARs, and other Java goodies) live and thrive.

Java isn’t just a language—it’s an entire ecosystem. Around it, new languages bloomed: Kotlin, Groovy, Scala, Jython, Clojure… like a botanical garden of syntax. Groovy even brought its own build tool to the party: Gradle. But under the hood, they all still rely on the trusty Maven artifact repository. Because why reinvent the wheel when you can just decorate it?

Whether you’re coding in Kotlin, Java, or Groovy—and building with Maven or Gradle—you can deploy your software packages to a Maven artifact repository. If you’re an open-source developer, Maven Central is the go-to. Yes, the process is a bit involved (signatures, validations, agreements), but hey, it’s all in the name of community safety. No one wants rogue JARs running wild.

But maybe you’re a solo dev, an adventurous coder, or a brilliant entrepreneur with the next billion-dollar idea. You’ve built a sleek authentication library, a dazzling auditing tool, or a game engine that makes players weep with joy. You want to reuse these gems across your projects without jumping through flaming hoops.

Creating a Maven package repository with Repsy takes seconds. Yes, literally seconds. Just register, and boom—your repository is born. And this delightful hippopotamus doesn’t stop there. It even uploads your very first package for you. Talk about service with a smile (and a snort).

Repsy Maven Artifacts

When you create a repository on Repsy, it starts off as a private Maven artifact repository—like a secret vault for your code. But if you’re feeling generous (or just want to show off your programming Picasso), you can flip the switch in the settings and make it public. Share your masterpiece with the world. Let your JARs shine.

Repsy isn’t just a pretty face—it’s packed with advanced features:

Prevent package overrides (because overwriting your magnum opus is a tragedy)
Control version allowance (no rogue versions sneaking in)
Webhooks (for when you want your CI/CD pipeline to throw a party)
Proxy support
Caching (because speed is life)

But let’s not get ahead of ourselves. This post is all about the basics: creating a Maven artifact and publishing it to Repsy.

Your Free 20 GB of Artifact Heaven

As mentioned earlier, Repsy gives you a free 20 GB Maven artifact repository the moment you register. That’s right—no setup rituals, no incantations. Just sign up, and your repository is ready to roll.

And the cherry on top? Repsy offers dynamic documentation. Hit the “Configure” button, and voilà—you’ll see tailored instructions for publishing and using your artifacts. It’s like having a personal guide who actually knows what they’re doing.

Repsy Maven Configure

Deploying to Repsy

Let’s make our hands dirty. For this post, we will create a library which is originally a JavaScript library. Formerly it caused a lot discussions around it. The library’s main purpose is finding a number is even or not.

Our directory hierarchy will be something like this:

.
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── io
│   │   │       └── repsy
│   │   │           └── iseven
│   │   │               └── IsEven.java
│   │   └── resources
│   └── test
│       └── java
│           └── io
│               └── repsy
│                   └── iseven
│                       └── IsEvenTest.java

And here comes our actual java class:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
package io.repsy.iseven;

public final class IsEven {
  private IsEven() {
    // Utility class, no instances.
  }

  public static boolean isEven(final int number) {
    return number % 2 == 0;
  }
}

as a good citizen and a developer, here is our unit test:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
package io.repsy.iseven;

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class IsEvenTest {
  @Test
  void isEven() {
    assertTrue(IsEven.isEven(2));
    assertFalse(IsEven.isEven(3));
  }
}

the final touch in our project. The touchstone of a maven project; pom.xml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<?xml version="1.0" encoding="UTF-8"?>
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>io.repsy</groupId>
  <artifactId>iseven</artifactId>
  <version>1.0</version>

  <properties>
    <maven.compiler.source>21</maven.compiler.source>
    <maven.compiler.target>21</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-engine</artifactId>
      <version>5.12.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

  <distributionManagement>
    <repository>
      <id>repsy</id>
      <name>My Private Maven Repository on Repsy</name>
      <url>https://repo.repsy.io/mvn/{{Current Username}}/test</url>
    </repository>
  </distributionManagement>
</project>

As you may notice we added a small dependency for our unit tests. Since we use a private maven artifact repository. We need a mechanism for storing our credentials for publishing our artifact/software package. The dynamic documentation section in Repsy is already providing the details of that file. For credentials you have some options in Repsy. Most used ones are:

Using our Repsy username and password
Using a repository specific deploy token

For the sake of simplicity. In this post we will use username/password. If we authenticated via Google, GitHub or GitLab SSO then we need to assign a password from profile section. If everything is properly set and we should have a username and password. As a next step, we can create a settings.xml file in our operating system home directory. This directory might be:

Mac/Unix/Linux users: /home/{{Current Username}}
Windows: C:\Users{{Current Username}}

In some cases this directory might be in different location.

With our favorite text editor application, we can create a file named settings.xml under .m2 folder inside the current user’s home directory

1
2
3
4
5
6
7
8
9
<settings>
  <servers>
    <server>
      <id>repsy</id>
      <username>{Our username}</username>
      <password>{Our password}</password>
    </server>
  </servers>
</settings>

If it’s already there, we just need to add server statement under servers tag. Please keep in mind, the server id must be equal to repository definition under distributionManagement in pom.xml file.

Now we can deploy our application to Repsy.

1
mvn deploy

If everything goes well you can see your artifact in the maven repository itself.

Using the deployed package

After a significant effort finally we made it and our package in our private maven artifact repository. But how can we use this library in our another Java project. Well, good thing is it’s already defined in Repsy’s dynamic maven documentation. Let’s create another project.

Our new project file hierarchy will be like this:

.
├── pom.xml
├── src
│   ├── main
│   │   ├── java
│   │   │   └── io
│   │   │       └── repsy
│   │   │           └── iseven_usage
│   │   │               └── Main.java
│   │   └── resources

For defining the needed dependency and the remote private maven repository we need a proper pom.xml file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<?xml version="1.0" encoding="UTF-8"?>
<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 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>io.repsy</groupId>
  <artifactId>iseven-usage</artifactId>
  <version>1.0</version>

  <properties>
    <maven.compiler.source>21</maven.compiler.source>
    <maven.compiler.target>21</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>io.repsy</groupId>
      <artifactId>iseven</artifactId>
      <version>1.0</version>
    </dependency>
  </dependencies>

  <repositories>
    <repository>
      <id>repsy</id>
      <name>My Private Maven Repository on Repsy</name>
      <url>https://repo.repsy.io/mvn/firat/test</url>
    </repository>
  </repositories>

  <build>
    <plugins>
      <plugin>
        <artifactId>maven-assembly-plugin</artifactId>
        <configuration>
          <archive>
            <manifest>
              <mainClass>io.repsy.iseven_usage.Main</mainClass>
            </manifest>
          </archive>
          <descriptorRefs>
            <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

In pom.xml there are some sections. dependencies is for declaring the dependency library that we want to use. Remote private maven repository may include different kinds of artifacts. So we need to define which one will be used. Every package is a unique in its own way. The repository they belong, a group id, an artifact name and also the version. The last 3 is generally called a maven coordinates. In gradle style representation our dependency’s maven coordinates are io.repsy:iseven:1.0

The other section is repositories the place you define all your private or public maven repositories. If there’s no such section in a pom.xml file that means the project uses maven central repository by default.

The other section is build section. As the name imposed, that section contains all build related adjustments. The maybe one of the most important one is the plugins section. We can enrich our build process with a variety of plugins. Some plugins help you test the code, somes check the code style, somes find possible bugs. Here, we are using maven assembly plugin to combine dependencies in a one single jar and make it executable. So it can be a portable executable java package.

Let’s continue with our Java file.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
package io.repsy.iseven_usage;

import io.repsy.iseven.IsEven;

public class Main {
  public static void main(final String[] args) {
    if (args.length == 0) {
      System.out.println("Usage: java -jar iseven_usage.jar <number>");
      System.exit(1);
    }

    try {
      final int number = Integer.parseInt(args[0]);
      System.out.println(IsEven.isEven(number) ? "Even" : "Odd");
    } catch (final NumberFormatException e) {
      System.err.println("Invalid number: " + e.getMessage());
      System.exit(1);
    }
  }
}

That was the final touch. We can compile and create a single jar file with dependencies.

1
mvn clean compile assembly:single

If everything went smoothly, we should e able to see a jar file in target directory. Now we can run that executable. In target folder.

1
java -jar iseven-usage-1.0-jar-with-dependencies.jar 12

And that’s a wrap on creating your very own private Maven repository! Repsy offers a surprisingly generous amount of space—20 GB for free—which is more than enough for solo developers and even small teams. Unless you’re trying to upload the entire internet, you’re probably good.

Plus, keeping a historical archive of your Maven artifacts is just smart. You never know when you’ll need to roll back to that one version that actually worked.

Let’s be honest: maintaining your own artifact repository sounds cool… until you’re knee-deep in server logs during a midnight outage. Using a cloud service like Repsy means you can focus on your core business—writing brilliant code, building amazing products, and occasionally Googling “how to fix that one weird bug.”

No server downtimes. No surprise security patches. Just smooth sailing and happy packaging.