Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
From: Stefan Bodewig <bodewig@apache.org>
To: general@gump.apache.org
Subject: Re: Advise wanted on build issues
References: <643F38D8535E4A7AA164D6CA61CF50D0@BillPC>
Date: Tue, 23 Feb 2010 06:22:51 +0100
In-Reply-To: <643F38D8535E4A7AA164D6CA61CF50D0@BillPC> (Bill Barker's message
	of "Sat, 20 Feb 2010 16:51:36 -0800")
Message-ID: <87ljekedas.fsf@v35516.1blu.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On 2010-02-21, Bill Barker <billwbarker@verizon.net> wrote:

> It looks like most of the problems related to castor-xml wanting to
> download an older version of itself are related to portals-pluto's
> dependency on it.

The castor-xml build is trying to download the trunk version of
castor-core from http://snapshots.repository.codehaus.org which isn't
proxied by the Maven proxy.  This means it will not get the version just
built - and there doesn't seem to be a jar available at codehaus.

So far I expected the build would heal itself at one point by a snapshot
jar becoming available, but I agree it has been taking a long time by
now.

One alternative would be to make the Maven proxy webapp aware of the
codehaus snapshots repo but that isn't trivial either (the current
webapp decides which real repository to use as fallback by looking at a
path prefix and there is none for this specific repository so multiple
fallbacks would be needed).

> The current Gump portals-pluto is the 1.0 version (which has been dead
> for years).  So one option is to switch it to be a packaged project.
> The other is to change portals-pluto to be the current version (which
> is the "Gump way").

The downstream dependencies of pluto are likely to require a newer
version at one point anyway.

> But that project is huge, and so would take considerable time to set
> up by anyone (such as myself) that isn't familiar with it.

It uses Maven 2 and a reactor, doesn't it?  If so you can start out with
a reactor build in a separate local repository and then add <option>s
for all things it downloads during the build.  This works pretty well.

> The castor-reactor build wants Maven 2.1, which is probably a good
> idea to be running on Gump.

True.

> I'm happy to do the upgrade for vmgump (and others, if granted access
> to them), but don't know how Maven 2 was installed in the first place.
> I'm guessing it was just downloaded and installed, but if it was
> installed by apt then it should be updated the same way.

No, it has been installed manually.
<http://wiki.apache.org/gump/VmgumpConfig> is likely outdated in many
ways by now, but at least for the Maven part it still tells the truth
8-)

> However, I'm not holding out hope that this will fix castor.

It may fix the reactor build.

> The lucene-java build is complaining that we have an ancient version
> of svn installed.  I'm guessing that this was installed by apt, but it
> would be nice to confirm before I try and update it.

It should be the apt version.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org