jira-importer opened a new issue, #156: URL: https://github.com/apache/maven-clean-plugin/issues/156
**[Peter De Maeyer](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=peterdm)** opened **[MCLEAN-125](https://issues.apache.org/jira/browse/MCLEAN-125?redirect=false)** and commented In complex multi-module projects with custom plugins, there is often a situation where one module populates the `target/` directory of _another_ (typically sibling or parent) module. While I agree that is not ideal and not recommended practice, it is sometimes the only way to work around limitations in plugins or build setups. Because of its design, the current `maven-clean-plugin` deletes these files too, breaking the build when doing a `mvn clean verify`. The workaround in such a case is to use `mvn clean; mvn verify` instead, note the semicolon. The reason is that in the first case the `target/` directory is cleared at the start of every module's build life cycle, clearing any needed files that a previous module has put there. The workaround `mvn clean; mvn verify` works, but it requires understanding of the user to correctly build the multi-module project, which is suboptimal. It would be better if that knowledge were embedded in the build script. ### Idea 1 To better support these situations, it would be useful to have for example a `cleanAtStart` option to the `maven-clean-plugin` that would clean _all_ modules during the "clean" phase of the first one. It would be similar and complementary to the `installAtEnd` option of the `maven-install-plugin`, or the `deployAtEnd` option of the `maven-deploy-plugin`. This would move the responsibility for correctly cleaning the project from the user to the build, where it belongs. Then users could do a plain `mvn clean install` while trusting the build script to take care of any of its own multi-module intricacies. I did some preliminary analysis of what it would take to implement this, using the `maven-invoker-plugin`'s `installAtEnd` as inspiration, but it's not so simple. The advantage that the `maven-install-plugin` has is that it can visit all the plugin executions of all the modules in a normal way and merely needs to defer the actual installation. And even that is a hack to work around the fundamental limitation that Maven itself has no support for this. Here, for the `maven-clean-plugin`, it is different: it needs to clean modules at the very start, before anything else, based on information that is not available yet 'coz the executions of the next modules hasn't been visited yet. Conclusion: it is impossible to implement due to lack of support from the Maven framework. ### Idea 2 Another idea is to only delete files based on modification time < build time, for example by configuring the Clean plugin with an `excludeBuildFiles` parameter. This would effectively delete files which were the result of _previous_ builds, but _not_ files which are the result of the _current_ build. This works assuming that: * Modification times of files produced in output directories are not manipulated. _If_ they are manipulated, this breaks the feature and files may be deleted while they're not supposed to, or the other way around. * Modification time is enabled on the file system and is granular enough to separate consecutive builds. Imagine for example the modification times are not granular enough so that two consecutive builds have the same build timestamp. That would mean files are not deleted when they're supposed to. On Linux timestamps have millisecond precision, and on Windows at least second precision AFAIK, which is good enough. Conclusion: this works quite well in practice. I'll create a PR for this. --- **Affects:** 3.4.0 **Remote Links:** - [GitHub Pull Request #63 ](https://github.com/apache/maven-clean-plugin/pull/63) -- 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]
