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

Maven does not require anything to install, or at least, am not getting
what you are saying.
OTOH, you DO need to install, if you plan to deploy (but, we can exclude
this part, as we agreed, let's stick to developer workstation case, and
developer do not deploy, CI is).

HTH
T

On Thu, May 5, 2022 at 9:58 PM Thomas Broyer <t.bro...@gmail.com> wrote:

> Because it is an antipattern?
> https://www.cloudbees.com/blog/maven-and-install-hack
>
> If you do rely on "mvn install", which one of your commit is your snapshot
> in your local repository from? How can you tell? And it gets worse if you
> deploy snapshots to a repository, as now it could also be from someone
> else's commit (you might not have pulled from your git repo, but the
> snapshot comes from the origin/master that someone else pushed)
>
> Maven is among the only (modern) build tools requiring you to "install"
> part of your project to some widely shared place (shared with all you local
> projects) to use it from within itself!
>
>
> Le jeu. 5 mai 2022 à 21:22, Tamás Cservenák <ta...@cservenak.net> a écrit
> :
>
> > Florent,
> >
> > Not directly related to your question, but reading your mail caught
> > my attention one sentence.
> > Can you shed some light on why "... but I'm trying to get rid of the need
> > for `mvn install` entirely."?
> >
> > Thanks
> > Tamas
> >
> > On Thu, May 5, 2022 at 3:11 PM Florent Biville <
> florent.bivi...@gmail.com>
> > wrote:
> >
> > > Hello everyone,
> > >
> > > TL;DR? https://github.com/fbiville/mvn-plugin-dependency-reactor-issue
> > >
> > > I recently noticed that, within the big multi-module project of my
> > company,
> > > a specific module is listed as a dependency to plugins such as Maven
> > > Checkstyle plugin or com.mycila:license-maven-plugin.
> > >
> > > The problem occurs when I try one of these plugins against another
> > specific
> > > module.
> > > Maven CLI will basically complain that it cannot resolve the module
> > needed
> > > by the plugin and fail, even if I explicitly list that module in the
> > > project list.
> > >
> > > That occurs both with Maven 3 and 4.
> > >
> > > The obvious workaround is to install the required module first and then
> > run
> > > the plugin but I'm trying to get rid of the need for `mvn install`
> > > entirely.
> > >
> > > Is there a particular reason plugin dependencies are not considered by
> > > Maven Reactor?
> > > Is module-as-plugin-dependency a Maven antipattern?
> > >
> > > Thanks a lot for your help!
> > > Florent
> > >
> >
>

Reply via email to