That's specifically an area I've tried to improve over the past months. Most plugins should avoid touching any output file if the content has not changed. Things have improved a bit, and with a bit of tuning, none of the jars is actually touched during a rebuild. Also, the build cache extension will definitely help with those use cases.
Anyway, one downside to the install is that if you're working on a custom branch, or even have checkout a tag, you kinda put in your local repo artifacts that you have no real control on. With the upcoming resolver new features, the separation of locally built artifacts and artifacts from remote repositories will help cleaning that stuff. Le jeu. 17 nov. 2022, 07:21, Olivier Lamy <ol...@apache.org> a écrit : > Agree not sure why such "marketing buzz around this" as the idea is to > share artifacts so they need to be installed or deployed. > The only issue I can see with install vs verify is the compilation of > everything all the time. > because m-compiler-p detects a new artifact of a module in the reactor > and so the m-compiler-p decides to recompile everything (because the > jar is newer than build start time). > I have some work locally but I still need to push the branch. > On very large projects (e.g lot of modules) it makes a significant > difference. > with install you will see "Changes detected - recompiling the module!" > whereas it's totally wrong (nothing has changed) > Maven core is even worse as well because of modello re generation even > if no changes. > it's definitely something here to improve (a sort of api where plugins > can tell there is some changes or not) > > On Sat, 12 Nov 2022 at 08:33, Tamás Cservenák <ta...@cservenak.net> wrote: > > > > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
