gnodet commented on PR #356: URL: https://github.com/apache/maven-clean-plugin/pull/356#issuecomment-5849874587
Thank you for the feedback! I'd like to clarify the use case a bit, because the problem this goal addresses isn't really about the `clean` goal itself. The issue (apache/maven-clean-plugin#315) describes a situation where a sub-module is removed or renamed from a multi-module build. After that, the old `target/` directory stays on disk indefinitely — even if you run `mvn clean`, because `clean` only cleans modules that are still in the reactor. The orphaned `target/` directory is effectively invisible to Maven. The typical scenario is: `git pull --rebase && mvn install`. A colleague removed or renamed a sub-module upstream; after the rebase the directory is gone from the POM but the `target/` is still there on disk. The next build happily picks up stale classes, reports, or generated files from it. This causes real problems with plugins that scan the project tree by filesystem path rather than by reactor membership: - **Apache RAT** recursively scans `target/` and fails on binary/generated files - **Checkstyle**, **SpotBugs**, **maven-site-plugin** can pick up stale classes or reports The `purge-check` goal addresses this by running in the `initialize` phase — before any of those plugins — and removing `target/` directories whose parent directory no longer has a `pom.xml`. It has to run at `initialize` precisely because `clean` is a separate lifecycle and isn't invoked during `validate`/`verify`/`install`; by the time RAT or Checkstyle run, `clean` is long gone. The heuristic is intentionally conservative: a directory is flagged as orphaned only if `target/` is its *sole* visible child, meaning the module was removed and nothing else lives there. A renamed module (with its own `pom.xml`) is left untouched. The intent is to bind this goal into both the `default` and `clean` lifecycles in Maven 4.1.0 (apache/maven#11800), so that orphan cleanup becomes automatic for all users without any plugin configuration — similar to how `maven-clean-plugin:clean` is already bound to the `clean` phase today. This PR is the first step toward that. Does that help clarify the rationale? Happy to adjust the implementation or the naming if you have suggestions. -- 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]
