install is a source of issues if you are in a multi-module project, you switch between branches and do not rebuild everything (because in general you still have the same coordinates between branches). In such case you can have binaries in m2 with one branch and rebuild some others modules partially in your project using these artifacts in another branch. I don't know how frequent can be this kind of issue, I tried myself to stay far from multi-modules as much as possible.
On Thu, Nov 17, 2022 at 9:17 AM Tamás Cservenák <ta...@cservenak.net> wrote: > Here it is described: > > https://maven.apache.org/resolver-archives/resolver-LATEST/local-repository.html#use-cases > > Also, sorry for typo Guillaume ;) > > T > > On Thu, Nov 17, 2022 at 9:15 AM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > ...aaand this is where "workspace" feature of split repo comes in play... > > oh Guillable, you already said it :D > > > > T > > > > On Thu, Nov 17, 2022 at 9:01 AM Guillaume Nodet <gno...@apache.org> > wrote: > > > >> 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 > >> > > >> > > >> > > > -- Arnaud Héritier Twitter/GitHub/... : aheritier
