Hi Fabian, I am going inspect all the plugins
Thanks for the great suggestion -Dan On Sun, May 1, 2016 at 11:55 PM, Fabian van der Veen < [email protected]> wrote: > Hey Dan, > > I think I've seen my extension still fail a few times as well, but it > wasn't reproducible enough to debug for me. It is still a concurrency issue > amongst the other problems; so it could simply be something I assumed > thread-safe API actually isn't thread-safe at all. (Which opens another > interesting dimension of problems, should that be true...) > On the other hand, I decided to tackle the core problem in our build > instead: removing aggregating plugin executions from anything but the root > pom. > > It might be a lot of work, but given how these plugins resolve their > dependencies, it might be for the best. (Besides the fact that, if I recall > correctly, these kinds of plugins are described as aggregating data from > the entire project.) > For example, in our case the javadoc plugin (amongst others) had the > aggregate goals declared in the root pom, but - unfortunately - these goals > simply get inherited to all child poms as well (causing the mentioned > problems). > > What we did was simply run the help:effective-pom target on the projects > (randomly) failing in a concurrent build; and check for all the resulting > plugin executions whether or not that goal was an aggregate goal or not. > With the list of offending plugins ready, we removed those that were > configured wrongly by developers. The ones left, we configured with > "<inherited>false</inherited>" in the plugin definition in the root pom; > which makes the plugin only configured and run on the parent. > > Actually working through the poms and fixing the offenders has made our > concurrent build 100% stable again. So while the extension does - in our > case, at least - certainly improve stability; it's still (unfortunately) > not a complete (easy) workaround. > > Hopefully this'll help you get your build stable again as well. Otherwise, > it'll be a waiting game until the issues I mentioned are picked up. > > - Fabian > > On vr, 2016-04-29 at 17:04 -0700, Dan Tran wrote: > > I dont see much improvement. I am seeing 2-3 fail build a day > > -D > > On Wed, Apr 20, 2016 at 12:40 AM, Dan Tran <[email protected]<mailto: > [email protected]>> wrote: > > > > Hi Fabian > > I will give your extension a try > > Thanks > > -Dan > > On Wed, Apr 20, 2016 at 12:26 AM, Fabian van der Veen < > [email protected]<mailto:[email protected]>> wrote: > > > > Hey, > > The way you describe it; this sounds like a problem I also encountered in > our (similar sized) project here. > I reported this here: https://issues.apache.org/jira/browse/MNG-5960, > which has been linked as related to > https://issues.apache.org/jira/browse/MNG-5750. > > Troubleshooting boiled down to running maven in debug mode; which might > be something you don't want to do. > In any case, I found that plugins running aggregate goals (e.g. > javadoc:aggregate) will resolve (compile) dependencies for _all_ projects > in the reactor. Running such a plugin in anything else than your root pom > might cause the random failures you have. (And having the plugin in your > root pom might also effectively include its configuration and execution in > child poms; which is "debuggable" using help:effective-pom.) > > Hopefully this helps you. > > - Fabian > > On di, 2016-04-19 at 12:08 -0700, Dan Tran wrote: > > Hi > > My 150+ modules with multi-thread build randomly error out with something > like this > > java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory > > > Have you encountered similar issue? how do you troubleshoot? > > > I am using maven 3.3.9 and latest compiler plugin > > > Thanks > > > -Dan > > > > > > >
