gnodet commented on issue #315:
URL:
https://github.com/apache/maven-clean-plugin/issues/315#issuecomment-5822471347
Thanks for the report, @elharo. This is a valid observation but it's the
wrong layer to fix it.
The clean plugin's responsibility is to delete the outputs declared by the
*current* reactor: `${project.build.directory}`, configured filesets, etc. A
submodule whose `pom.xml` has been deleted is simply not part of the reactor
when `mvn clean` runs — the plugin has no way to discover it existed, let alone
what it produced.
Fixing this properly requires Maven core to maintain a **build state
registry**: a record of which directories were written by previous builds,
persisted across sessions. Once core provides that information, the clean
plugin could consume it to also remove orphaned past outputs. But the state
tracking belongs at the core level, not here.
Please open an issue in the [apache/maven](https://github.com/apache/maven)
project to track this feature request. The linked issues
([apache/maven#11800](https://github.com/apache/maven/issues/11800) and
[apache/maven-resolver#1943](https://github.com/apache/maven-resolver/issues/1943))
are related context.
In the meantime, the workaround is `find . -maxdepth 3 -name target -type d
| xargs rm -rf` from the project root, or `git clean -fdx` if you want to fully
restore the working tree to a clean checkout state.
Closing as out of scope for this plugin.
--
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]
