You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Dan Fabulich <da...@fabulich.com> on 2010/01/07 03:45:58 UTC

Dependening on jars, concurrency modes

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.

-Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Dependening on jars, concurrency modes

Posted by Brian Fox <br...@infinity.nu>.
On Wed, Jan 6, 2010 at 9:45 PM, Dan Fabulich <da...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org