As we have spoken with Maven Central publishers about sustainability, one pattern has appeared repeatedly: a surprising amount of what reaches Central was never really intended for downstream consumers.
It is not malicious, reckless, or even particularly unusual. More often, it is the accumulated result of build defaults, release conventions, legacy configuration, and automation that nobody has had a strong reason to revisit.
A benchmark JAR is attached to every release because the build has always done that. Test fixtures are published even though nothing outside the organisation consumes them. A development server is assembled as a shaded JAR and quietly becomes part of the public release bundle. The same machine-readable metadata is published in multiple formats. Files are formatted for human readability even though only machines will ever process them.
Individually, these choices can look trivial. Repeated across modules, releases, publishers, and years, they become infrastructure.
This is another area where Maven Central's sustainability work is proving more nuanced than a simple conversation about limits. Publishing less does not necessarily mean releasing less often, supporting fewer users, or reducing the value of a project.
Sometimes it simply means taking a closer look at what a release actually contains.
The word "waste" needs some care. It can imply negligence or deliberate excess. That is not what we are seeing in most publisher conversations. The more common pattern is that locally reasonable decisions have accumulated into globally inefficient ones.
Modern build systems are designed to automate. Plugins attach artifacts. Parent configurations are inherited. Release pipelines package whatever they have been told to package. Once a process is stable, there is an understandable reluctance to interfere with it.
The result may be a public release containing:
Artifacts used only for internal benchmarking;
Shaded executables created for local development;
Test JARs and test sources with no external consumers;
Duplicated metadata in multiple serialisations;
Generated files whose formatting adds size but no machine-readable value;
Modules that continue to publish because they once had a downstream use;
Release outputs that nobody has reviewed as a complete bundle.
None of these necessarily represents misuse of Central. They are better understood as publishing decisions whose original context has disappeared.
This is why visibility matters. Until publishers can see the size and composition of their releases, it is difficult to distinguish what is essential from what is simply present.
Developers tend to think about artifacts one module at a time; Central sees the aggregate.
A few unnecessary files in one module may be insignificant. The same files generated across dozens of modules, several repositories, and frequent release cycles produce a very different outcome.
That distinction mirrors a broader theme in this series. Many behaviours that create infrastructure pressure are sensible when viewed locally. It is their repetition at scale that changes their effect.
A test JAR may be small. A source archive may be expected. An SBOM may be valuable. A shaded artifact may genuinely be required.
The question is not whether a particular classifier or file type is inherently wasteful. It is whether that specific file serves a downstream purpose in that specific release.
Without that context, a blanket rule would be unhelpful. Some projects publish reusable test harnesses that other developers genuinely depend on. Others attach test artifacts automatically even though they are never consumed. Some projects need an executable distribution. Others accidentally publish a development-only server alongside a library.
The filename alone does not tell us which case we are looking at.
One of the clearest examples from our conversations came from a commercial publisher whose release volume had placed it above the initial usage guidance.
The organisation shall remain anonymous here, but its experience is worth sharing because the improvements did not come from reducing legitimate releases or changing what its users received.
The team began by examining what its build was preparing for publication.
They created a small audit script that effectively dry-ran a release, inspected the resulting bundle, and reported:
The expected total release size;
The size of each module;
The contribution of different artifact classifiers;
The files responsible for the largest parts of the release.
The implementation was deliberately pragmatic rather than polished. What mattered was that it turned a largely invisible release process into actionable information.
That review uncovered several categories of avoidable output. Benchmarking modules were producing large shaded JARs that were useful for continuous performance testing but had no value to downstream consumers. Some repositories also assembled development servers as fat JARs so that engineers could exercise a library locally. Those servers were useful inside the development workflow, but there was no reason to distribute them through Central.
The team also reviewed test JARs and test-source JARs module by module. Where a reusable test harness or contract-test suite had a genuine downstream purpose, it remained. Where the artifact was only consumed internally, or not consumed at all, it was removed from the public release.
The result was not marginal.
Across three reporting periods, the organisation's total release size fell from roughly 3 GB, to 1.5 GB, and then to around 300 MB. Its release count and frequency remained broadly similar. The reduction came primarily from publishing more deliberately, not from doing less software delivery.
That is an important distinction.
The publisher did not optimise for a number by compromising its product. It identified things that were never useful to Central's consumers in the first place.
The same review produced a less obvious finding.
Once the largest accidental artifacts had been removed, software bills of materials became a noticeable proportion of some release bundles.
That does not mean SBOMs are waste. They are useful software transparency artifacts, and their richness is part of their purpose. But they are also machine-readable documents that can become large for projects with deep dependency trees.
In this case, the publisher had been producing the same semantic information in more than one serialisation. It moved to publishing only the format it actually used downstream.
The team also noticed that the SBOM files were pretty-printed by default. Indentation and whitespace are helpful when a human is expected to read a document, but much less useful for an artifact primarily intended for machine consumption.
The publisher contributed an upstream change that made compact output easier to generate, then began working towards using it from its build tooling. On some larger modules, removing unnecessary formatting saved around 100 to 150 KB per SBOM. That is not transformative in isolation, but repeated across modules and releases it is another example of avoidable volume becoming visible only after somebody looked closely.
This also demonstrates why sustainability work should not stop at individual publisher configuration.
Sometimes the waste is reinforced by tooling defaults. Fixing it at the source can improve behaviour for everyone who uses that tool later.
The examples above point to several distinct categories.
These are files that support development, testing, benchmarking, or internal operations but do not form part of the public interface of the project.
They may be useful. They may even be essential to the publisher's own engineering process. That does not mean Central is the right place to distribute them.
This is the clearest form of avoidable publishing: a valid artifact delivered to an audience that does not exist.
Metadata may be generated in XML and JSON, compressed and uncompressed forms, or through several overlapping plugin outputs.
Sometimes consumers genuinely require those alternatives. Sometimes they are published because each tool has independently attached its preferred format.
Where two files represent the same information and only one is used, publishing both creates cost without creating corresponding value.
A software factory creates many things on its way to producing a release. Intermediate packages, development servers, diagnostic bundles, generated test fixtures, benchmark executables, and temporary assemblies may all be legitimate build outputs.
They are not automatically public release artifacts.
Central is intended for public distribution of release-ready components, not as the permanent destination for everything a pipeline can produce. That distinction has been part of our sustainability framing from the beginning.
A module may once have had downstream users. A classifier may have been required by an old toolchain. A release profile may have been copied from a parent project years ago.
Public artifacts are easy to add and difficult to question because removing one can create compatibility concerns. Caution is appropriate. But caution should not prevent publishers from establishing whether an artifact is still used.
The important step is not indiscriminate deletion. It is evidence.
Some artifacts are necessary but larger than they need to be.
Pretty-printed machine documents are one example. Repeated embedded dependencies, unintentional shading, uncompressed resources, or generated metadata containing redundant detail may be others.
The goal should not be to shave every byte. Engineering time also has a cost, and extreme optimisation can create complexity that outweighs the infrastructure benefit.
The useful question is whether a relatively simple change removes meaningful repetition without reducing utility.
One of the lessons from the anonymous publisher is that the first useful tool was not a policy engine or a complex platform.
It was a report.
Before the audit script existed, the release process worked, but the team did not have a clear view of what the complete publication bundle contained. Once the contents were grouped by module, artifact type, and size, the obvious candidates became obvious.
That suggests a practical direction for both publishers and infrastructure stewards.
Publishers need better visibility before release, not only a total after publication. A useful release review could answer:
What is going to be published?
Which files are new?
Which modules account for most of the size?
Which classifiers are attached?
How does this release compare with the previous one?
Does each artifact have an identified downstream purpose?
These questions should not require a manual forensic exercise every time. Ideally, build and release tooling should make the shape of a publication easy to inspect.
The fact that one publisher built its own audit script is encouraging. It is also a sign that the wider ecosystem may be missing a useful class of tooling.
There is a danger that a conversation about waste turns into an obsession with minimisation.
That would be the wrong lesson.
Source JARs, documentation, signatures, provenance, SBOMs, checksums, and metadata all have legitimate roles. A larger artifact may provide better usability. A reusable test fixture may save many downstream teams from recreating the same thing. Multiple formats may be necessary where ecosystems have not converged.
Sustainability should not become an excuse to remove useful material or make releases harder to consume.
The standard is not "publish the fewest possible bytes."
It is "publish what creates downstream value, and understand why it is there."
That leaves room for judgement. It also aligns with the approach we have taken to community open source exemptions: numerical signals can tell us where to look, but they cannot replace context.
Reducing unnecessary publication is not only about lowering the load on Central.
Smaller and clearer releases can also mean:
Faster build and release pipelines;
Less storage and transfer inside the publisher's own systems;
Easier investigation when release size unexpectedly changes;
Fewer accidental public disclosures;
Simpler downstream dependency choices;
Greater confidence that the published surface matches what the project intends to support.
The anonymous publisher's audit was motivated by Central usage visibility, but the work also gave the team a clearer understanding of its own release process.
That is a recurring characteristic of good infrastructure optimisation. Removing waste from a shared system often exposes waste in the local system that created it.
Individual publishers can review their release bundles, but the ecosystem should not rely entirely on every team discovering these problems independently.
Build tools and plugins shape publishing behaviour. Defaults that attach artifacts automatically, generate duplicate outputs, pretty-print machine-only files, or make it difficult to inspect a release bundle can create aggregate cost across thousands of projects.
Most users will follow the default path. That makes defaults a form of infrastructure policy, even when nobody intended them to be.
The strongest outcome from a publisher discovering waste is therefore not only that one publisher changes its configuration. It is that the learning flows upstream:
Into plugins;
Into parent POMs;
Into release tooling;
Into documentation;
Into better visibility before publication.
The publisher in our example did exactly that by contributing a change to an upstream SBOM library rather than keeping the optimisation entirely local.
This is how local sustainability work can become ecosystem improvement.
Maven Central should make it easy to distribute useful software to the Java ecosystem.
That does not require every build output to become a permanent public artifact. Nor does it require publishers to minimise releases until they become inconvenient or incomplete.
It requires intent.
A release should contain the binaries, metadata, documentation, security information, and supporting artifacts its consumers genuinely need. Where something exists only for the publisher's own engineering process, there are usually better places to keep it. Where the same information is distributed twice, it is reasonable to ask whether both copies are necessary. Where a file is large because of a tooling default, it is worth considering whether that default can improve.
These decisions are small when made once. Central experiences them across the ecosystem.
Our sustainability work began with the visible questions of scale, limits, commercial usage, and community exemptions. Those remain important. But the publisher conversations are also revealing a more constructive opportunity: helping everyone understand what they publish and remove what no longer serves a purpose.
The best waste is not the waste we price, store, or optimise more efficiently.
It is the waste that never enters the system.