Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ivo.koga@gmail.com designates
 64.233.166.176 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=HFkeq8B8SbWOAnMkAB0A93+luZa/poEav4HsVHv7Z19/8i067z+788xzTVLDFYriNl+cPb6mQrfO1hhofdNB0LHnkFDJgT7B4S/Kth+5WdWSoee6Jt5DhGg4KeH9AY1B9xFzp4h7QSfCxzxtMBi7tF8tbEpMHLD7WWSO6BSD7hc=
Message-ID: <d0a9683b0607130832m4c07aa58ua3abee173780e738@mail.gmail.com>
Date: Thu, 13 Jul 2006 12:32:03 -0300
From: "Ivo Koga" <ivo.koga@gmail.com>
To: felix-dev@incubator.apache.org
Subject: Re: Problem trying installing Felix
In-Reply-To: <44B60161.3060204@ungoverned.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15694_11783653.1152804723751"
References: <d0a9683b0607122031s258ad647mde40a3b76ec639c@mail.gmail.com>
	 <3379950E-68F4-4B5A-826C-BDABA83B37AE@luminis.nl>
	 <44B60161.3060204@ungoverned.org>

------=_Part_15694_11783653.1152804723751
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Marcel,

I=B4ve just tried to build it again and it didn=B4t work.

I made a new checkout from svn and typed: mvn clean install and got the sam=
e
error. :-(

Regards,

Ivo K. Koga


On 7/13/06, Richard S. Hall <heavy@ungoverned.org> wrote:
>
> Definitely, I agree. We need to pin down our build process to make it
> more stable, since we have been bitten by this type of thing more than
> once.
>
> This also highlights the need for us to get an actual Felix release of
> some sort out the door with a simplified build process that bypasses
> this stuff.
>
> Regarding the snapshot repository, I think that is for our OSGi Maven
> plugin...from my experience, the plugin needs to be in a repo otherwise
> you cannot initially build bundles that require it. There might be a way
> around this, such as requiring a manual install of the plugin into the
> local repository, but I am not sure.
>
> It seems better if we could somehow order the repos so that Maven would
> search them in order, thus we could put the snapshot repository
> last...or something.
>
> -> richard
>
> Marcel Offermans wrote:
> > Hello Ivo,
> >
> > I just talked to the maven developers (on the codehaus irc #maven
> > channel) and they quicky fixed the problem. There was an issue with a
> > specific plugin that they fixed. Please try building again. Try
> > building again!
> >
> > To all: we really need to review the way we build with maven.
> > Appearantly, because we include a snapshot repository in our build, we
> > automatically get a snapshot version of everything else too, which
> > basically means we're running on a very unstable version. This has
> > bitten us a couple of times now.
> >
> > Now, I'm not sure why we include this snapshot repository, but the
> > advice on the #maven channel was to see if we could remove that from
> > our pom.xml (the <pluginRepository> that points to a snapshot
> > repository). Did anybody add that one for a specific reason?
> >
> > Our other option would be to manually "pin down" each individual
> > plugin we use in the build. I got a hint on that, we should somehow
> > specify "build > plugins > plugin > version" for each plugin. This
> > seems a lot of work though, so I'd rather go for the default of not
> > going for snapshots at all.
> >
> > Greetings, Marcel
> >
> >
>

------=_Part_15694_11783653.1152804723751--