Subversion on sourceforge refuses to make copies

If you find that SourceForge's subversion system is buggered (again) and
refuses to let you make copies, it could be because you hadn't noticed
their not-very-well-advertised switch of access URL to:

"On November 31, 2006 the access method for Subversion changed. This
document reflects those changes. The old method had numerous problems,
including spurious 50x error messages and other issues that kept it from
functioning fully. This newly documented access method solves many, if
not all of the issues with the old mechanism.

Users of the old method
(https://svn.sourceforge.net/svnroot/PROJECTNAME) should switch to the
new access method
(https://PROJECTNAME.svn.sourceforge.net/svnroot/PROJECTNAME) using
these steps:

1. Make a copy of your local working copy.
2. Run 'svn info' at the root of the repository content, it should
display a line that appears similar to: URL:
https://svn.sourceforge.net/svnroot/PROJECTNAME/trunk
3. Run the following command at the root of the working copy: svn
switch --relocate
https://svn.sourceforge.net/svnroot/PROJECTNAME/trunk
https://PROJECTNAME.svn.sourceforge.net/svnroot/PROJECTNAME/trunk

SVN is a complex tool."

Right, and it doesn't get any easier when SourceForge keep arseing about
with it.

http://sourceforge.net/docman/display_doc.php?docid=31070&group_id=1#notice

AstroGrid registry bug with namespaces

We've recently upgrade our WFAU publishing registry to version Version
2006.3.03r. This has introduced a bug where previously registered
entries cannot be edited. When you submit the edits you get a:

env:ServerServer Error: No namespace defined for prefix vororg.exist.xmldb.LocalXPathQueryService.compile(LocalXPathQueryService.java:213) org.exist.xmldb.LocalXPathQueryService.doQuery(LocalXPathQueryService.java:280) org.exist.xmldb.LocalXPathQueryService.query(LocalXPathQueryService.java:112) org.exist.xmldb.LocalXPathQueryService.query(LocalXPathQueryService.java:103) org.astrogrid.xmldb.client.XMLDBServiceImpl.queryXQuery(XMLDBServiceImpl.java:235) org.astrogrid.registry.server.xmldb.XMLDBRegistry.query(XMLDBRegistry.java:71) org.astrogrid.registry.server.admin.AuthorityListManager.getManagedAuthorities(AuthorityListManager.java:118) org.astrogrid.registry.server.admin.AuthorityListManager.populateManagedMaps(AuthorityListManager.java:106) org.astrogrid.registry.server.admin.RegistryAdminService.updateResource(RegistryAdminService.java:282) org.apache.jsp.admin.addResourceEntry_jsp._jspService(addResourceEntry_jsp.java:488) org.apache.jasper.runtime.HttpJspBase.service(H
ttpJspBase.java:94) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:292) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:236) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapp
Valve.java:214) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) org.apache.catal
ina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:540) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) org.apache.c
atalina.core.ContainerBase.invoke(ContainerBase.java:929) org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) java.lang.Thread.run(Thread.java:595)

The fix is to copy the
xmlns:vr="http://www.ivoa.net/xml/VOResource/v0.10" from the
vor:Resource into the root vor:VOResources element.

VOMon - the VO service monitor has been released:

VOMon - the VO service monitor has been released:

http://vomon.sourceforge.net

VOMon is a mashup of the Astro Runtime
<http://www2.astrogrid.org/desktop/astro-runtime> and MARS
<http://leapfrog-mars.sourceforge.net/>, glued together with Python.
VOMon uses the Astro Runtime to query a Registry to obtain all the
services that match an admin-specified query. By default it queries the
central AstroGrid registry, but can be configured to query any
IVOA-compliant registry. This list of services is updated every hour or
so, so that VOMon will always have a reasonably up to date list of
services to monitor. The services are passed to MARS which does the
actual monitoring. Currently this monitoring consists of simply
pinging the accessURL and checking the response. Some services such as
Cone and SIAP, have default parameters appended to the accessURL to
ensure they do not fail. Once the VOSI interface is widely supported,
VOMon will be upgraded to use that. VOMon can either output a report to
be hosted on a web server, or present the user with a GUI interface.

An instance has been deployed at:
http://thor.roe.ac.uk/vomon/status.xml

Weekly Summary

* Prepared proposal for JISC CoP participation
* Plastic Website maintenance http://plastic.sourceforge.net and
general email business
* Finally, published IVOA Plastic Note:
http://ivoa.net/Documents/latest/PlasticDesktopInterop.html