Le jeu. 17 nov. 2022 à 19:16, Arnaud Héritier <aherit...@gmail.com> a écrit :
> 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. > Isnt verify the same since in a multimodule you can't just build a submodule without missing a dep? Depends how you work on the project IMHO, but building from the root a multimodule is not the unique way to work with big projects (on very big project opening only submodule saves your time!) so guess both options have pro and cons and should be used as needed but enforce an understading of your commands as usual. > > 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 >
