Maven

With Reo.dev, you can now identify and monitor downloads of your open-source artifacts through Maven. This short guide will walk you through how this works and how you can set it up.

How open-source Maven Artifacts are downloaded

Developers who want to install your OSS package through Maven will typically execute a command like this:

mvn dependency:get -Dartifact=YourSoftware:version1

When this command is executed, the developer's system will download the Maven artifact of your software hosted on Maven Central.

Since Maven Central is maintained by Sonatype, you will normally get only limited, aggregated analytics of downloads of your Maven artifact → such as aggregate counts of artifact downloads, origin countries of download requests, aggregation of cloud services initiating a download and domain classification (business, ISP, education) etc.

You will not get download-specific information, or the ability to de-anonymize Maven downloads at user or organization level.

This level of detail isn't useful to GTM motions as it does not identify the actual company or developer initiating the download.

Reo.dev Maven Redirection

Reo.dev uses a redirection system for Maven commands helps you achieve this enhanced visibility. Here's how: Reo creates a redirection layer that sits in front of your Open Source Software packages - whether they're on Maven Central, GitHub, GitLab or anywhere else.

Users then replace the default pull command:

mvn dependency:get -Dartifact=YourSoftware:version1

with a domain-specific command:

mvn dependency:get -Dartifact=YourSoftware:version1 -DremoteRepositories=https://yourcompany.com

Note: "https://[yourcompany.com](<http://yourcompany.com/>)" serves as a proxy for actual package registry and is not a host of the package.

Your Maven artifacts will continue to be hosted at Maven Central / Github or any other repository that you originally configured. Savvy users can always directly pull from the original package hub without anything breaking.

When a mvn dependency:get command is executed with the new domain-specific command, the request is redirected (307 redirect) on to the original registry for package download.

Reo.dev can map multiple packages to multiple registries. Each package will need a unique URL on "yourcompany.com" which maps to the correct package repository.

Example:

yoursoftware/version1 -> <https://yourcompany.com/yoursoftware/version1>

yoursoftware/version2 -> <https://yourcompany.com/yoursoftware/version2>

yoursoftware/betasoftware/version08 -> <https://yourcompany.com/yoursoftware/betasoftware/version08>

Since this redirection service and the URL (https://yourcompany.com/YourSoftware) is maintained by Reo.dev, you will now get far richer insights on the user downloading your software, just as if you were hosting it yourself.

You will get:

Information	Description
IP Level De-anonymization	De-anonymized accounts that have downloaded your Maven artifact derived from their IP address
Company-level aggregation of Repository downloads	We aggregate Maven downloads across an identified organization to create picture of adoption levels.

Final Flow Summary

Step	Description
1	User runs mvn with https://yourcompany.com
2	Request hits Maven endpoint of https://yourcompany.com
3	Request is proxied to reo.dev
4	reo.dev issues a 307 redirect to actual registry
5	Maven CLI downloads artifact from registry

The redirection system ensures that while you gain enhanced visibility into who is downloading your packages, the actual downloads continue to happen directly from the original registries, maintaining performance and reliability.

Configuration Setup

Once you configure the Reo redirection system, your users will have the option to use the new URL to pull Maven artifacts. Update your documentation and Gtihub release notes to reflect the new URL.

💡 Note: Your Maven artifacts will continue to be hosted at Maven Central / Github or any other repository that you originally configured. Savvy users can always directly pull from the original package hub without anything breaking.

Certificate Setup for HTTPS

To enable secure access, a TLS certificate for your custom domain (e.g., yourcompany.com) is required.

Issue a TLS Certificate: This certificate can be created yourself or by reo.dev for you. Get a TLS certificate from a trusted provider. Let's Encrypt offers free certificates, Amazon provides them through ACM if you use AWS, or you can purchase one from any established certificate company.

Update DNS & Install the Certificate: If reo.dev servers handles traffic or redirects for the domain (yourcompany.com), DNS records for that domain would need to point to reo.dev servers.

The TLS certificate would also need to be installed on reo.dev servers. It's important to note that only the yourcompany.com domain requires the certificate - no other domains in the setup need certification. While the certificate can be issued and installed by either by you or reo.dev, it must be from a trusted source that client systems will recognize and accept.