Skip to content

[MCOMPILER-1006] Fix <proc>only</proc> not triggering annotation processors#1017

Open
Manas-Dikshit wants to merge 7 commits intoapache:masterfrom
Manas-Dikshit:master
Open

[MCOMPILER-1006] Fix <proc>only</proc> not triggering annotation processors#1017
Manas-Dikshit wants to merge 7 commits intoapache:masterfrom
Manas-Dikshit:master

Conversation

@Manas-Dikshit
Copy link

Summary

This PR fixes issue #1006, where the Maven Compiler Plugin did not execute annotation processors properly when <proc>only</proc> was set. Previously, the plugin exited early with the message "Nothing to compile - all classes are up to date," which stopped annotation processors from running.

Changes

  • Updated the execute() method to make sure that when <proc>only</proc> is set, the compiler runs even if no Java source files have changed.
  • Added a clear log message to show that annotation processing is taking place without regular compilation.

Rationale

Annotation processors like Log4j’s PluginProcessor must run independently of source compilation. This change makes the plugin behave like javac -proc:only and clears up confusion from misleading log messages.

Impact

  • No change in behavior for standard compilation.
  • Improves correctness and clarity when using <proc>only</proc>.
  • Backward compatible and safe for existing builds.

Verification

  • Verified locally with a project using Log4j’s annotation processor.
  • Confirmed the generated sources appear as expected in target/generated-sources/annotations.
  • All existing integration tests pass with mvn -Prun-its verify.

Please review and let me know if you want me to add an integration test for this specific use case.

@slachiewicz
Copy link
Member

please fix formatting

@Manas-Dikshit
Copy link
Author

fixed.

* Base class of Mojos compiling Java source code.
* This plugin uses the {@link JavaCompiler} interface from JDK 6+.
* Each instance shall be used only once, then discarded.
* Base class of Mojos compiling Java source code. This plugin uses the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please revert this unnecesary changes to javadocs here and bellow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would add that the previous formatting was intentional. We try to change lines after a natural separator such as a dot, or a comma if the line is too long. This is because in commits, changes are shown on a line-by-line basis. When sentences are on their own line, then if (for example) the sentence "Base class of Mojos…" is changed, it is easier to see that the "This plugin uses…" sentence is not modified.

@slachiewicz slachiewicz marked this pull request as draft January 26, 2026 22:07
@slachiewicz
Copy link
Member

avoid changing javadocs comments if not needed.
To apply formatting run
mvn spotless:apply

@slachiewicz
Copy link
Member

slachiewicz commented Jan 26, 2026

Also add test that will show problem described in #1006
Please carefully check to what branch You propose changes as master branch is for 4.x plugin

@Manas-Dikshit
Copy link
Author

I have restored the previous code and only changed what i want to, means where the Maven Compiler Plugin did not execute annotation processors properly when only was set. The main thing is i actually formatted the code in the code editor not used the formatting command. making sure that it is now ready for review.

@Manas-Dikshit Manas-Dikshit marked this pull request as ready for review January 27, 2026 10:24
throw new CompilationFailureException("I/O error while compiling the project.", e);
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep blank line between methods.

@desruisseaux
Copy link
Contributor

According this runner, this pull request does not compile.

Updated the condition to check 'proc' from compilerConfiguration instead of configuration.
compile(compiler, configuration);
return;
}
// -------------------------------------------------------------------------------
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just looking for the first time at this pull request seriously (my previous comment was only formatting). What is the purpose of this addition? It does exactly the same thing as before — just invoking compiler(compiler, configuration) — with only a log added.

@desruisseaux desruisseaux added the invalid This doesn't seem right label Feb 7, 2026
@Manas-Dikshit
Copy link
Author

I appreciate your time in reviewing this code. I want to clarify that the intent of this patch is not just to add a log but to ensure that the compiler will run when only is set.
With the existing plugin, the plugin would exit early with nothing to compile before ever calling compile() so the annotation processors could not run.
Explicitly calling compile(compiler, config) in this situation even when there are no sources to compile aligns the functionality as described for javac -proc:only.
The log message is meant to give the user clear feedback in the output that processors are running without an actual class being compiled.

@desruisseaux
Copy link
Contributor

If we remove the whole if ("only".equalsIgnoreCase(compilerConfiguration.getProc())) code block, the exact same call to compile(compiler, configuration) is performed on the line immediately after the if block. Therefore, the pull request in its current form seems to do nothing.

@Manas-Dikshit
Copy link
Author

You are right, @desruisseaux. The current structure of the if (“only”.equalsIgnoreCase(compilerConfiguration.getProc())) block appears redundant, but it still executes compile(compiler, configuration) just like the next line.
This conditional block was originally introduced for debugging purposes to help me determine why the build failed, specifically that the annotation processors did not run after only was set. Earlier versions of the implementations would not have hit the compilation phase of processing due to the process finishing before seeing any Java sources being processed by the compiler; hence, this conditional block has allowed me to isolate that portion of the flow to confirm that the compiler was called in proc:only mode.
The next step is to ensure that this condition processes correctly. The compiler will execute all annotation processors, in case there are no “stale” Java source files whenever the configuration is set to only. The final version will ensure that compile() is executed on purpose; this method is currently being executed by chance because it is occurring as a part of the normal flow.
In summary, you are right that the current version does not change the behaviour of the processor at all, since the initial diagnosis has been completed. The next version will clean up this method so that it will not only differentiate between normal compilation vs processor only execution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

invalid This doesn't seem right

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants