On Nov 23, 2012, at 8:20 AM, Benson Margulies <[email protected]> wrote:
> On Fri, Nov 23, 2012 at 10:16 AM, Jason van Zyl <[email protected]> wrote: >> On Nov 23, 2012, at 3:13 AM, Jochen Wiedmann <[email protected]> >> wrote: >> >>> Would be happy about comments on >>> >>> >>> http://grumpyapache.blogspot.de/2012/11/rfc-improving-mavens-performance.html >>> >> >> The fastest incremental turn around for a Maven build anywhere in any tool >> that exists is inside m2e. That said it is incredibly hard to get right >> because people almost never consider Maven beyond the command line >> invocation and almost never take into account incremental behaviour in their >> plugin code. It is an after thought. Some helper code can be useful but it >> boils down to understanding how to make something truly incremental and its >> incremental behaviour in relation to other parts of the build. Everyone >> always complains about the "execution not covered" in m2e but that >> illustrates the problem and is the crux of the problem. If all plugins used >> the incremental APIs that are utilized in m2e -- and they were activated >> within Maven -- you would have fully incremental builds. Incremental builds >> in m2e and the command-line are essentially the same problem and there is >> code for that which has been working for years. >> >> I do not believe that anything needs to happen at the beginning of the >> lifecycle to avoid any particular phase. The cost of checking is in the >> plugin itself is where it needs to happen, walking through the build plan >> up-front I do not think is necessary as an m2e build setup correctly -- yes >> it can be a bear -- works very quickly. I can fully work on and debug Guice, >> Sisu, and Maven in a single workspace and I can execute Maven from within >> the workspace on a test project near instantaneously after a change. It's >> possible, it does work already, it just needs some adaptation to the CLI > > Jason, how does any of this deal with more complex inter-plugin > dependencies? If there are inter-plugin dependencies not handled generally the plugin is written wrong. Why? An arbitrarily large number of plugins can never possibly know the requirements of other plugins. At each phase all resources need to be left in such a way that any subsequent plugins can deal with them deterministically. > For example, I've had to turn off the JAR plugin's > incremental behavior, because of MSHADE-126. The shade plugin's > activities invalidate the jar plugin's assumptions. That's simply wrong, it can never scale as a general solution. That still does not imply you need an overarching mechanism to manage all plugins interacting with one another. > I've implemented > the M2E interfaces for one or two things, and I don't recall seeing a > solution to that in there? That's because it's not required. > Having individual plugins invent and > maintain progressively more complex mechanisms of leaving behind > little tripwires that detect other plugins' actions does not seem > scalable to me. Plugins are responsible for their own incremental behaviour, at the boundary of each phase resources are left in a known state for subsequent operations. I certainly do not advocate one plugin leaving breadcrumbs for other plugins. That certainly is not a scalable. > > >> >> The reason we've (Igor, Benjamin and myself) been slow in attempting to >> back port all this is that most of the users we ask work in the IDE all the >> time. We help people setup in Eclipse with m2e and help make the necessary >> changes to import and have large complex projects working. When they do >> build from the CLI or the CI server it's generally a clean build. I agree it >> would be highly useful to have near instantaneous feedback from the CI >> server but the use case we get back over and over is the IDE-first use case >> and that can work deadly fast. You can take a look at the >> maven-resources-plugin if you want an example of how the incremental APIs >> work. >> >>> Thanks, >>> >>> Jochen >>> >>> -- >>> The best argument for celibacy is that the clergy will sooner or later >>> become extinct. >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder & CTO, Sonatype >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> A language that doesn’t affect the way you think about programming is not >> worth knowing. >> >> -- Alan Perlis >> >> >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- You are never dedicated to something you have complete confidence in. No one is fanatically shouting that the sun is going to rise tomorrow. They know it is going to rise tomorrow. When people are fanatically dedicated to political or religious faiths or any other kind of dogmas or goals, it's always because these dogmas or goals are in doubt. -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
