gnodet commented on issue #315:
URL:
https://github.com/apache/maven-clean-plugin/issues/315#issuecomment-5803621855
This is a valid observation, but I think it's pointing at the wrong layer.
The clean plugin's responsibility is to delete the outputs declared by the
*current* project: `${project.build.directory}`, configured filesets, etc. It
correctly does so. The scenario described here — a submodule whose `pom.xml`
has been deleted but whose `target/` remains — cannot be handled by the clean
plugin alone, because at the time `mvn clean` runs, the deleted submodule
simply isn't part of the reactor anymore. The plugin has no knowledge that it
ever existed.
Fixing this properly would require Maven core (or the resolver) to maintain
a record of previous build outputs across sessions — essentially a build state
database keyed to the project directory. That's what the linked issues
[apache/maven-resolver#1943](https://github.com/apache/maven-resolver/issues/1943)
and [apache/maven#11800](https://github.com/apache/maven/issues/11800) are
tracking. Once Maven core provides that information, the clean plugin could
consume it — but the state tracking itself belongs at the core level.
In the meantime, the workaround is to delete orphaned `target/` directories
manually or via a shell glob (`find . -maxdepth 3 -name target -type d | xargs
rm -rf`).
Closing as out of scope for this plugin; the fix needs to come from Maven
core.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
