Howdy, in relation to this PR (the reasoning behind it): https://github.com/apache/maven-mvnd/pull/734
I never really understood people unconditionally forcing verify instead of install. For me, personally, the "final output" of the build was always what it installs. While we do call internally the target directory as "buildOutput", it is more like "build temp", full of intermediate files, class files, temp files, state files, and who knows what. To find the final output in target you need to dig in, sift through files and/or directories (possibly needing knowledge even how some plugin is configured, or worse, working). In the local repository, it's all on coordinates: just check the POM GAV you built, no need for any other knowledge (of plugin, of config or whatever). Clear as it can be. And ultimately, a Maven project's ultimate dream goal is to be deployed, and what is installed, pretty much (most often) will be the same as will be deployed. Again, win-win. Finally, to me this feels like it is being pushed by people who "stick" to their local repository a bit too much :) For them, there is a "split local repository" feature, where installed and cached stuff is clearly separated (and hence, easy to nuke). Or in other words, I stick to the mantra "what is not in a (local or remote) repo, does not exist (for Maven)". And most often you do want to reuse (depend on) the project being built, hence "sharing" (installing for local dev or deploy for remote dev) is wanted. I see verify being better for trivial cases, like you work on a simple (single or multi module) project, with a trivial (known to behave) set of plugins. But in a moment when you work on two or more interconnected projects, or non trivial projects, or just using some "nasty" plugin that for some reason tries to resolve things and is unaware of the project, etc, mvn verify quickly becomes a problem. WDYT? Thanks T
