Hm, By reading this blog entry from 2012 (!), I see it summarizes nicely at the end: * You may be using some broken plugins that you will need to fix, or replace. * You may be battling a circular dependency hell (which was why you used dependency:copy in the first place) which indicates a bad build smell that you should eradicate. * You may not have the time… well think of all the time you are wasting running "mvn install" when you could get away without going so far along the lifecycle.
Can you point me to some "reproducer" project (of ANY of these issues mentioned in this 10 year old blog), that * will reproduce this with modern Maven, think 3.8.x * is NOT broken topologically (cycles), is not using broken (by using broken plugins) and developers does have time? Thanks 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 > > > > > >
