Repository navigation
AggregatorSourceJarMojo silently does nothing for non-POM packaging #306
Description
AggregatorSourceJarMojo.java:35-37:
@Override
protected void doExecute() throws MojoException {
if (Type.POM.equals(getProject().getPackaging().type().id())) {
packageSources(reactorProjects);
}
}If the aggregator project has non-POM packaging, the method returns without any warning or error message. While @Mojo(aggregator = true) typically implies POM packaging, a misleading build or configuration could lead to silent failure — no source JAR is produced and the user receives no indication why.
Fix: Add an else branch with a warning or info message explaining why no sources were packaged.
Activity
kratos0718 commentedon Aug 5, 2026
Taking this one.
Planning to add the
elsebranch with a warning naming the project and its actual packaging, in the style of the existing classifier warning inpackageSources, plus a unit test covering both branches — thatpackageSourcesruns forpompackaging and that non-POM packaging warns instead of returning silently.elharo commentedon Aug 5, 2026
I wonder if this one should fail instead of logging?
kratos0718 commentedon Aug 12, 2026
Good question, and I think a warning is the safer choice here.
Today an aggregator run against a non-POM project succeeds silently — it just produces no source JAR. Switching that to a failure would break builds that pass right now, and the people most likely to hit it are exactly those with an incidental aggregator binding they never noticed. That is a behavioural change rather than a bug fix.
The actual complaint in this issue is diagnosability, not permissiveness: the user gets no indication why nothing was produced. A warning naming the project and its real packaging solves that completely, without breaking anyone:
That said, if the project does consider a non-POM aggregator binding to be unambiguously a misconfiguration, then failing is defensible — I would just want it tied to a major version rather than a patch, since it can turn a green build red with no change on the user's side.
Happy to implement either. Unless you would rather have the failure, I will open a PR with the warning plus a test asserting the message is emitted and that the build still succeeds.