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