Sorry, Brian...my comment was aimed at Jason Dillon. :-)
Yes, I agree that the plugin in charge of something like compilation should be able to inform the rest of the build as to whether or not that action really took place. I think that sort of thing could lead to a build short-circuiting and stopping if an early plugin (or, enough early plugins) can determine that nothing needs to be done. -john On 1/30/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:
yep, I like the way that train of thought is going...:) On 1/30/07, Brian E. Fox <[EMAIL PROTECTED]> wrote: > Yes, understood. However, only the compiler plugin would be able to know > if during this run anything was actually compiled. If it communicated > that somewhere, then other plugins could make decisions. > > -----Original Message----- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 30, 2007 10:46 AM > To: Maven Developers List > Subject: Re: [PROPOSAL] maven-build-context (Shared context for Maven > components and plugins) > > One important thing to remember is that this is a build-time context, > not a database or other type of persistent storage. If you wanted to > detect farthest-progress between builds, you'd have to look in some > other place (maybe a file, or just a timestamp comparison of the > end-product artifact vs. the sources or something... > > The point is, this could help make a single build process more > efficient, but not a series of builds. > > -john > > On 1/29/07, Jason Dillon <[EMAIL PROTECTED]> wrote: > > > > That would be nice! If the default set of plugins would only do work > > if something really changed. Then one could hope that `mvn install` > > would do a bunch of stuff, and if nothing changed the `mvn install` > > again would complete much, much quicker. But more importantly running > > > `mvn deploy` after `mvn install` would just re-use the previously > > packaged artifacts and not recompile or repackage anything. > > > > --jason > > > > > > On Jan 29, 2007, at 6:23 PM, Brian E. Fox wrote: > > > > > I can think of several use cases for this. The most obvious would be > > > > the ability for jar to determine if compile or resources actually > > > made any changes and decide if repackaging is needed. > > > > > > -----Original Message----- > > > From: Wendell Beckwith [mailto:[EMAIL PROTECTED] > > > Sent: Monday, January 29, 2007 4:55 PM > > > To: Maven Developers List > > > Subject: Re: [PROPOSAL] maven-build-context (Shared context for > > > Maven components and plugins) > > > > > > I've read the doc and the irc and while I can see the benefit to a > > > shared context, I'm curious as to whether the current pressing need > > > is coming more from maven or the kepler project? Doesn't matter > > > either way just looking for the origin of the pain. This proposal > > > looks to satisfy some of the OSGi builds issues I have encountered > > > if maven's project build order was in the shared context and a > > > plugin/componet could update /modify that order such that OSGi > > > bundles could be built easier with maven. > > > > > > Wb > > > > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For > > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] For > > additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jesse mcconnell [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
