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 >> > >> > >> >
