[
https://issues.apache.org/jira/browse/MCLEAN-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MCLEAN-125.
------------------------------------------
Resolution: Won't Do
This sounds like an excessively complex workaround for something that shouldn't
be happening in the first place.The target directory belongs to the module or
submodule that created it, no other. Nothing else should be putting files there.
> Don't clean files put in the output directory by previous modules during the
> same build
> ---------------------------------------------------------------------------------------
>
> Key: MCLEAN-125
> URL: https://issues.apache.org/jira/browse/MCLEAN-125
> Project: Maven Clean Plugin
> Issue Type: Improvement
> Affects Versions: 3.4.0
> Reporter: Peter De Maeyer
> Priority: Major
>
> 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.
> h3. 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.
> h3. 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
