Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of brianf@reply.infinity.nu
 designates 205.210.42.66 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Is it now possible to affect reactor build ordering without using
 a  normal module dependency?
Date: Fri, 3 Apr 2009 16:13:18 -0400
Message-ID: <2BABBE7D2A66E04DB8A66A527D29927E53C210@intrepid.infinity.nu>
In-Reply-To: <8B81F0C3-C113-40A4-8BD6-318FAF556735@yahoo.com>
Thread-Topic: Is it now possible to affect reactor build ordering without
 using a  normal module dependency?
Thread-Index: Acm0ihIrnhaXXckQTkq7Yo4kZLpjSwADoXFg
References: <b727c560904030911v64f40abeo5137ffcb8660fbb1@mail.gmail.com>
 <30D63B30-1664-4F7E-AEAC-48D3192FFBB6@yahoo.com>
 <2BABBE7D2A66E04DB8A66A527D29927E53C209@intrepid.infinity.nu>
 <8B81F0C3-C113-40A4-8BD6-318FAF556735@yahoo.com>
From: "Brian E. Fox" <brianf@reply.infinity.nu>
To: "Maven Developers List" <dev@maven.apache.org>

That's what I want in maven 3, but it's not there yet.=20

-----Original Message-----
From: David Jencks [mailto:david_jencks@yahoo.com]=20
Sent: Friday, April 03, 2009 2:29 PM
To: Maven Developers List
Subject: Re: Is it now possible to affect reactor build ordering without
using a normal module dependency?


On Apr 3, 2009, at 10:14 AM, Brian E. Fox wrote:

> It's because a plugin may have a defacto dependency based on something
> in its configuration. Maven won't know about this so if that dep is in
> the same reactor, it may not be ordered correctly. The dependency:copy
> is an example of this. There should be a way for a plugin to =20
> participate
> in the reactor ordering for cases like this. There's a proposal but I
> can't find it at this time.

Hmmm....

I guess when I read the dependency plugin docs and it said that it =20
could download artifacts all by itself it didn't really register.  I =20
don't really understand any point of view other than these required =20
artifacts are dependencies that happen to be declared only in the =20
plugin configuration, not in the normal dependencies section of the =20
pom.  As such I'd expect that if you don't want to have to explicitly =20
list them as dependencies then the plugin ought to get a chance to add =20
dependencies during some kind of setup phase.  I have a plugin for =20
which this would be extremely handy.  Is this what is planned for 3.0 =20
or is there another point of view I have yet to comprehend?

thanks
david jencks

>
>
> -----Original Message-----
> From: David Jencks [mailto:david_jencks@yahoo.com]
> Sent: Friday, April 03, 2009 12:34 PM
> To: Maven Developers List
> Subject: Re: Is it now possible to affect reactor build ordering =20
> without
> using a normal module dependency?
>
> Why do you want to affect the reactor build ordering without using a
> dependency?
>
> The only use for something like this I have thought of.... so this
> might be a feature request.... is that I would like to be able to
> assure that a large project with deeply nested structure can be built
> in stages.  For instance if I have a project like this:
>
> base
> -sub1
> --p1
> --p2
> -sub2
> --p3
> --p4
>
> where base, sub1 and sub2 are pom packaging and p1...p4 have the code
> in them,
>
> I would like to be able to assure that all of sub1 gets built before
> any of sub2 to assist in preventing any dependencies of p1 or p2 on p3
> or p4.  AFAICT the current behavior is that maven puts p1...p4 in a
> single bucket and tries to find a build order that satisfies the
> dependencies.
>
> thanks
> david jencks
>
>
>
> On Apr 3, 2009, at 9:11 AM, James Carpenter wrote:
>
>> In the past plugins such as the dependency plugin didn't have a way =20
>> to
>> affect the reactor build order without having the user add a real
>> dependency
>> (say test scope) to the module using the plugin (or having the plugin
>> programatically do the same) just to ensure proper build ordering.
>> I assume
>> this problem will eventually be solved in some manner (say a ghost
>> dependency scope), but that it is likely a difficult one for some
>> reason or
>> other and therefore has not been solved long ago.
>>
>> If all the referenced artifacts are jars one can sometimes
>> workaround the
>> problem using plugin dependencies like I did when enhancing the
>> exec:java
>> plugin for non-java modules.
>>
>
http://mojo.codehaus.org/exec-maven-plugin/examples/example-exec-using-p
> lugin-dependencies.html
>>
>> I am about to write a plugin which automatically downloads a few
>> archives
>> specified by GAVs, and I'm wondering if the situation has improved.
>> If not
>> I will simply use have to work around the issue.  Can anyone provide
>> some
>> color the current status of this issue?
>
>
> ---------------------------------------------------------------------
> 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
>


---------------------------------------------------------------------
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