You can miss a dep, but there's an enforcer rule to make sure you don't https://maven.apache.org/enforcer/enforcer-rules/reactorModuleConvergence.html
My pain is having to always `clean install` because of an MCOMPILER bug affecting just one module, and by extension all of them. I wont mention which bug - suffice to say there are such edge cases. Delany On Thu, 17 Nov 2022 at 21:01, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > 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 > > >
