On Wed, Jan 6, 2010 at 9:45 PM, Dan Fabulich <d...@fabulich.com> wrote: > Kristian Rosenvold wrote: > >> 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. > > http://github.com/krosenvold/maven3/issues/#issue/3 > > Actually, upon thinking about the antrun bug a little further, I realized > that there's something weird about the antrun project I gave you: it fails > in Maven 2.x when you run "mvn compile" but works if you run "mvn package" > (because the dependent project relies on the packaged jar). > > Assuming such projects should be supported, even single-threaded weave mode > would fail unless it could somehow know that the dependent's project > generate-sources phase relies on the package phase of the earlier project. > > If this is unknowable, then we'd have to be able to fall back onto Project > Granularity, the simplest (slowest) concurrency mode that could possibly > work. >
Until we have a fully declarative model that can allow us to interrogate a plugin's intentions, I don't see how you could always know if a dependency does in fact exist. > -Dan > > --------------------------------------------------------------------- > 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
