I recently spent many hours modifying nexus-public in order to finally get a workable APT repository implementation. I want to share this experience because I think it illustrates a deeper problem with how Sonatype handles open source in Nexus.
Some background
I’ve been using Sonatype Nexus for a very long time — probably over 10 years at this point. I clearly remember, more than a decade ago, several JIRA issues open about fundamental missing features in APT repository support. I kept hoping these would eventually get filled.
Time passed. I found workarounds. Life went on.
Ten years later, almost nothing has changed in APT repository support. The big missing features are still missing — namely, support for multiple distribution codenames and multiple component names (anything other than main).
Recently, I decided enough was enough.
Digging into the code
Nexus is written in Java. My Java is rusty, but I took the time to set up my environment, understand the codebase, and pinpoint exactly what was missing. This took a lot of effort, since it’s not my codebase and there is very little documentation on how to properly set up a development/debugging environment for Nexus.
Eventually I found my way through it. I made all the modifications needed to nexus-repository-apt to add the features I’d been waiting for:
-
Multi-distribution support
-
Multi-component support
-
XZ compression
I was genuinely proud of getting through this. It’s not a trivial codebase to approach from the outside.
Then reality hit
Here’s where the story turns sour: even after making all these changes, I can’t actually run my own fix.
I can’t deploy it to my own infrastructure, which uses the official sonatype/nexus3 Docker image, because nexus-public only contains part of the source code. I tried to work around this — again, with zero documentation to guide me — and spent hours trying to monkey-patch the Docker image to slot in my modified nexus-repository-apt jar.
This is deeply frustrating, and it defeats the whole point of being open source in the first place. The point of open source — going back to the origins of the GNU project — is to let engineers fix their own problems. If I can’t actually run my fix, what good is having the source available?
Nexus is “open core,” but in practice, you need non-free components just to get the open parts running in a real deployment. If I go through the trouble of writing a fix, it’s because I need it — and being blocked from using it defeats the purpose.
The final straw
After all this, I opened a Pull Request against nexus-public. It was only then that I noticed: no pull requests have been merged in months.
At that point, it becomes hard not to conclude that the “open” part of Nexus’s open source strategy exists mainly to satisfy license compliance, not to build a real relationship with the community. There’s very little indication that outside contributions are wanted, reviewed, or valued.
Why I’m posting this
I don’t want this to just be a rant. I’d like to know:
-
Has anyone else run into this same wall trying to run custom builds of
nexus-repository-apt(or any other plugin) against the official Docker image? -
Is there a documented, supported way to build and deploy a custom OSS plugin jar into a Nexus instance?
-
Has anyone had better luck getting PRs reviewed/merged on
nexus-public? Is there a preferred contact path (mailing list, community call, etc.) that actually gets traction with Sonatype?
I’d genuinely like this to improve. Multi-distribution/multi-component APT support is not an exotic feature request — it’s basic functionality that many self-hosted Debian/Ubuntu repo users need. I’m happy to share my patch and continue pushing on the PR if there’s any indication it will actually be looked at.