Howdy, no, not my memory, I rely on my "daily routine": I use Maven Repository Manager, I regularly nuke my local repo, regularly execute `git clean -fdx` on my checkout, and on checkout/branch change regularly do "quick-build" `mvn clean install` (usually `mvn clean install -Dtest=void`) as very first step. Have to add, I tend to work on projects that finish these "quick builds" in a matter of minutes at most, not hours :) This "process" works for me just fine.
But, now that you bring up topic of "branched development", something I always hated for very same reason you bring up, I think you will be happy to see upcoming changes: https://github.com/apache/maven-resolver/blob/master/src/site/markdown/local-repository.md (unreleased yet, we plan this for Resolver 1.8.1 and Maven 3.9.0). All in all I think we both agree, but still: Maven as a project is big (huge actually), and volunteers working on it have hard time to catch up, like that compiler plugin bug, so as ecosystem, as a whole is very resource demanding to "keep up", and I bet (in a six pack) that there are a LOT MORE places where legacy APIs are used from plugins, also missing "workspace resolution" the very same way compiler misses it. Please help us, by reporting these (ideally with a reproducer). Am not saying either "maven is the best", but I am convinced "maven can be better", MUCH better and we will do it. As a matter of fact, we are already doing it, step by step, baby steps :) HTH T On Fri, May 6, 2022 at 11:00 AM Thomas Broyer <t.bro...@gmail.com> wrote: > > So you rely on your memory (when was the last time I ran 'mvn install'? did > I switch branch or changed the code since then?) and you end up running > 'mvn install' all the time, "just in case". > (checking the sha means that target/XXX.jar is up-to-date with the code > too, i.e. you ran 'mvn package', which brings use back to relying on your > memory) > > Also, if you 'git pull' or 'git switch', how can you tell whether you > actually need to rebuild (and re-install) that piece of code? You have to > look at the changed files from the previous state and rely on assumptions > about whether they'll change that thing that you have to 'mvn install' to > make your build work; or I bet you'll actually just blindly 'mvn install' > every time. > > See my other answer (to your other mail), there ARE cases (admittedly few > of them, but still) where you DO have to rely on 'mvn install'. > > Note: I'm not here to debate about whether Maven is "good" or "good > enough", better than other tools or not (I made my opinion years ago, I'm > not asking you to change my mind). Maven is a good tool and we owe it many > things, it really helped make the whole Java (and more) development > experience better and inspired many other tools; but it DOES have > limitations, and people have to be aware of them. And I'll stand by what I > said: 'mvn install' is an anti-pattern. Even using one project from another > (a lib you're developing, from some sample project using it) should be > possible without 'mvn install', through an aggregator build (this is mostly > the case, but there are exceptions). In other words, I should be able to > 'cd' into a project and 'mvn verify' it and it should Just Work™ without > relying on some "ambient" state such as "when did I last 'mvn install' that > thing? am I actually using the 'correct version' of it?". > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> < > http://xn--nna.ma.xn--bwa-xxb.je/> >
