2010/1/6 Kristian Rosenvold <kristian.rosenv...@gmail.com>: > On Wed, 2010-01-06 at 22:36 +1100, Brett Porter wrote: >> On 06/01/2010, at 10:15 PM, Kristian Rosenvold wrote: >> >> > - Given that parallel execution is an "alternate" mode that may have >> > additional constraints, does 3.0 need something that is guaranteed to >> > work for the vast majority of projects ? I think Dan's implementation >> > does this already, while the Weave build would probably get there around >> > 3.1-3.2 if it is exposed as "experimental" through 3.0. >> >> At a superficial level, this sounds like a great approach to me - a "safe" >> concurrent build by default, easily disabled for traditional style builds, >> with the infrastructure in place to make it much more and let people kick >> the tires. > > I really like your "kicking the tires" metaphor, which is exactly what > I've tried to make possible by modularizing the > DefaultLifecycleExecutor. When the execution strategies are in separate > components the concurrent stuff can be kicked around a lot easier and > safer ;) > > >> >> > The only significant difference between the weave mode and the regular >> > mode is that the complete execution plan is determined up-front. As a >> > consequence of this the ReactorArtifactRepository (line 83) is forced to >> > use compile output from upstream modules when in weave mode, which means >> > jar files from other modules are not used in weave mode. This is also >> > the reason for the problem with the Antrun plugin, I believe. I'll have >> > to go jogging (skiing), to come up with how to solve this. >> > >> > I'll look at the eclipse:eclipse issue ASAP. >> >> I may not fully grok this statement, but you certainly want all builds to >> utilise the same resources and behave the same way, no matter what mode they >> are operating in... >> >> Anyway, waiting for my flu to clear so I can dig into some of this in more >> detail :) >> > > My mentor in my first job always said "The devil is in the details - the > interesting stuff is there". Luckily there haven't been that many devils > yet. The ReactorArtifactRepository already supported this mode of > operation, so I just nudged it slightly when in weave mode. The reason > for this was to minimize the latency between dependent modules; if > dependant modules have to wait for "install" to complete you lose a lot > of concurrency. In this case I have at least one other suggestion as to
however you might have to wait for "install" as the attached artifact can be replaced in the reactor, e.g. maven-shade-plugin could be replacing the artifact with its shaded version you only know by the time you hit install (or the last phase in the invoked lifecycle, whichever comes first) that the attached artifacts are the final attached artifacts for consumption by dependent modules > how this could be handled. > > There's some really interesting discussions we can have on this topic, > I'll give you some time to absorb the current work first ;) > > Just to make sure no-one panics; this stuff happens only in weave mode. > > Kristian > > http://twitter.com/krosenvold > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
