Board Report Q1/2010

2010-03-12 Thread Stefan Bodewig
Infrastructure:

* No news is good news.

Technical:

* the installation is chugging along with active metadata
  maintenance.

* we've updated the installed version of Maven to 2.2.1 which has
  tightened its verification process for plugins or so it seems.
  The current approach taken by Gump won't work anymore when we'd
  want to perform integration tests for Maven plugins themselves,
  but fortunately there currently is none followed by Gump that
  would be under active development.

Other:

* still all Apache committers have access to metadata in svn.

* no releases.

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



Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml

2010-03-12 Thread Bill Barker



--
From: Stefan Bodewig bode...@apache.org
Sent: Thursday, March 11, 2010 5:38 AM
To: general@gump.apache.org
Subject: Re: svn commit: r920715 - /gump/metadata/project/excalibur.xml


On 2010-03-11, Bill Barker billwbar...@verizon.net wrote:


If you have any ideas why portals-pluto-trunk can't find it's parent,


It isn't even trying to download it.  Since I don't know enough about
Maven I can't say why a repository may get disabled, but

[DEBUG] Skipping disabled repository central
[DEBUG] portals-pom: using locally installed snapshot
[DEBUG] Skipping disabled repository central
[DEBUG] Using mirror: http://localhost:8192/maven2 (id: gump-central)

sounds suspicios.



Yeah, downloaded the src distro for maven 2.2.1, and it is that it is that 
the 'central' repo is disabled for SNAPSHOTs (and it is looking for a 
SNAPSHOT POM).  So Maven never asks to get it (even though it is there). 
The work-arounds that I've seen are too complex for Gump, and the project is 
largely dormant, so for the moment will just let it fail.


Of course, if there are any Maven gurus lurking here with better ideas, 
would love to hear them.



In particular, if there was an access-log (that I haven't found), this
would be great.  The mvnrepo log doesn't show it at all, but looks
like it only logs 200 OK requests.


The proxy uses ju.logging and I think it should be logging to stdout by
default which should make it end up in Gump's own log file (since this
is the parent process).  I can't promise it would log failed requests,
though.

Stefan

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



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