Skip to content

AggregatorSourceJarMojo silently does nothing for non-POM packaging #306

Closed
#320
Closed
AggregatorSourceJarMojo silently does nothing for non-POM packaging#306
#320
Labels
bugSomething isn't workingpriority:minorMinor loss of function, or other problem where easy workaround is present

Description

@elharo
elharo
opened on Jul 20, 2026

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

  1. elharo
    added
    bugSomething isn't working
    priority:minorMinor loss of function, or other problem where easy workaround is present
    on Jul 20, 2026

  2. kratos0718 commented on Aug 5, 2026

    @kratos0718
    kratos0718
    on Aug 5, 2026
    Contributor

    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.

  3. elharo commented on Aug 5, 2026

    @elharo
    elharo
    on Aug 5, 2026
    ContributorAuthor

    I wonder if this one should fail instead of logging?

  4. kratos0718 commented on Aug 12, 2026

    @kratos0718
    kratos0718
    on Aug 12, 2026
    Contributor

    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.

  5. elharo
    closed this as completedin #320on Sep 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority:minorMinor loss of function, or other problem where easy workaround is present

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions