On Thu, May 5, 2022 at 10:22 PM Tamás Cservenák <ta...@cservenak.net> wrote:
> IMHO the antipattern here is the idea that "mvn install" is bad. > > But let's take it step by step. For simplicity sake, let's ignore remote > deploys/downloads for now. > Also, let's assume a developer workstation for the same reason > (simplicity). > > Q: which one of your commit is your snapshot in your local repository from? > A: the last one you `mvn install`-ed? > > Q: how can you tell? > A: Your build should be reproducible ( > https://maven.apache.org/guides/mini/guide-reproducible-builds.html) so > you > can sha target/XXX.jar and local repo? But if unsure, just `mvn install` :D > 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. > Maven does not require anything to install, or at least, am not getting > what you are saying. > 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/>
