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 kristian.rosenvold@gmail.com
 designates 209.85.219.225 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=RtoU6qV6VEm7z/RVthiitDL5daVwmF9qv0BhksMioNRWAAlOZRZfnusbYN59zXCWeE
         LcaHC2LBM9EHdWVXFodVbZX0atbSXhUiSzg70+4eI3uakSUpU26vBqH7bbs+Vmrawcia
         MASipQHU++fFAglxSE+Vo7vI042y6zmjU5ctg=
MIME-Version: 1.0
In-Reply-To: <4B78D838.7090205@ifedorenko.com>
References: <CDE1AF6C-19B5-4828-8631-CE0B017CBC59@visi.com>
	 <0A0F9CC7-4756-4FAC-9FCF-EDBEC6490A40@apache.org>
	 <1265483784.11375.23.camel@office>
	 <0C52D4B3-0389-4114-A642-3DB0FC509C0C@apache.org>
	 <42a010a61002080118x382e3999hc22571212ef80947@mail.gmail.com>
	 <88c1b41002080158g7c6eb3b0lbceee7ed944ffd9c@mail.gmail.com>
	 <42a010a61002080320k31c4b8f5pafaf4b88f1122c87@mail.gmail.com>
	 <4B6FF437.8090901@udo.edu> <1266093271.1550.30.camel@office>
	 <4B78D838.7090205@ifedorenko.com>
Date: Mon, 15 Feb 2010 08:51:20 +0100
Message-ID: <42a010a61002142351h5d5cd051q8624473d50aae4ee@mail.gmail.com>
Subject: Re: Artifact instances in a reactor build
From: Kristian Rosenvold <kristian.rosenvold@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=00c09f76b41e00361b047f9ee24c

--00c09f76b41e00361b047f9ee24c
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Feb 15, 2010 at 6:14 AM, Igor Fedorenko <igor@ifedorenko.com> wrote:

> I am not 100% sure, but I think this may break MavenMetadataCache, which
> caches Artifact instances and assumes they do not change. In m2e, for
> example, we do not flash the cache before each build, only when project
> pom.xml changes. So if one of mojos changes cached Artifact instance,
> next build may misbehave.
>

Nice tip; I checked the code and there seem to be no dependencies on the
mutable parts of
DefaultArtifact. If it were up to me I'd just make most of DefaultArtifact
final and immutable...

It seems like Brett is right; the "file/resolved" bit in DefaultArtifact
probably shouldn't have been
there, and when I think about it it's probably just used within a single
module build in linear maven. It seems
to me like the artifacts are re-resolved "properly" when proceeding to the
next module; this works
well with clear module boundaries ;)

ATM I solved this problem by re-resolving reactor artifacts when a module
transitions into
packaging, but I'll see if I can improve that once I find out why surefire
won't fire consistently ;)

Kristian

--00c09f76b41e00361b047f9ee24c--