AggregatorSourceJarMojo silently does nothing for non-POM packaging

[elharo]

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.

[kratos0718]

Taking this one.

Planning to add the else branch with a warning naming the project and its actual packaging, in the style of the existing classifier warning in packageSources, plus a unit test covering both branches — that packageSources runs for pom packaging and that non-POM packaging warns instead of returning silently.

[elharo]

I wonder if this one should fail instead of logging?

[kratos0718]

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:

[WARNING] Not packaging sources for org.example:my-app: aggregator goal
requires "pom" packaging but project packaging is "jar".

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.