BATCH: Unable to send...

2005-03-08 Thread brutus
Dear Gumpmeisters,

The following 1 notifys should have been sent

*** G U M P
[EMAIL PROTECTED]: Project wsfx-axis-types (in module muse) failed
*** G U M P
[EMAIL PROTECTED]: Project wsfx-axis-types (in module muse) failed
Failed with to: [EMAIL PROTECTED] from: [Ian Springer ipsATapacheDOTorg]
Failed to send notify e-mail: (450, 'FQDN required in the envelope sender', 
'ipsATapacheDOTorg')
To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project wsfx-axis-types has an issue affecting its community integration.
This issue affects 2 projects,
 and has been outstanding for 16 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- muse :  Muse Project
- wsfx-axis-types :  Muse Project


Full details are available at:
http://brutus.apache.org/gump/public/muse/wsfx-axis-types/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [wsfx-axis-types-08032005.jar] identifier set to project 
name
 -DEBUG- Dependency on wsdl4j exists, no need to add for property 
maven.jar.axis-wsdl4j.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/muse/axis-types/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/muse/axis-types/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/muse/axis-types/project.properties
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/muse/wsfx-axis-types/gump_work/build_muse_wsfx-axis-types.html
Work Name: build_muse_wsfx-axis-types (Type: Build)
Work ended in a state of : Failed
Elapsed: 6 secs
Command Line: maven --offline jar 
[Working Directory: /usr/local/gump/public/workspace/muse/axis-types]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/muse/target/classes:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/ws-axis/java/build/lib/axis.jar:/usr/local/gump/public/workspace/ws-axis/java/build/lib/saaj.jar:/usr/local/gump/public/workspace/ws-axis/java/build/lib/axis-ant.jar:/usr/local/gump/public/workspace/ws-axis/java/build/lib/jaxrpc.jar:/usr/local/gump/public/workspace/xml-security/build/xmlsec-08032005.jar:/usr/local/gump/public/workspace/wsdl4j/build/lib/qname.jar:/usr/local/gump/public/workspace/wsdl4j/build/lib/wsdl4j.jar
-
[javac] Compiling 5 source files to 
/home/gump/workspaces2/public/workspace/muse/axis-types/target/classes
generate:
[echo] Writing generated Axis types to: 
/home/gump/workspaces2/public/workspace/muse/axis-types/target/generated/src
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/muse/axis-types/target/generated/src
[echo] Generating Axis types for WSDL: 
/home/gump/workspaces2/public/workspace/muse/src/bindings/WS-ResourceLifetime-1_2-bindings.wsdl
[java] log4j:WARN No appenders could be found for logger 
(org.apache.axis.i18n.ProjectResourceBundle).
[java] log4j:WARN Please initialize the log4j system properly.
[java] WSDLException (at 
/definitions/import/wsdl:definitions/wsdl:types/xsd:schema/xsd:schema): 
faultCode=OTHER_ERROR: An error occurred trying to resolve schema referenced at 
'xml/XML-Namespace-1998.xsd', relative to 
'file:/home/gump/workspaces2/public/workspace/muse/src/wsdl/spec/wsrf/WS-BaseFaults-1_2.xsd'.:
 This file was not found: 
file:/home/gump/workspaces2/public/workspace/muse/src/wsdl/spec/wsrf/xml/XML-Namespace-1998.xsd:
 java.io.FileNotFoundException: This file was 

Re: brutus disk full again

2005-03-08 Thread Adam R. B. Jack
  We probably could make all our workspaces share the same cvs
  directory, i.e. the directory holding the clean working copies,
  this would give us a few GB additional disk space.

We could (for the least amount of coding effort) probably have gump lock
each module's root directory as it attempts an update (cvs|svn) so that we
could share the download repository. Since we have this part multi-threaded
(and working in back-ground threads w/ the core build thread waiting as
needed) it oughtn't matter if the lock was initiated by another thread, or
another process. We'd replicate the effort of cvs|svn figuring out what
updates (often none) where needed, but that is no big deal. There are other
approaches, but this seems easiest/cheapest within the code.

BTW: If not already, could things like stray locks get filed into JIRA,
just in case I ever do find myself spare cycles? [That, and if JIRA ever
reminds me of my account information so I can go check.]

regards,

Adam


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: brutus disk full again

2005-03-08 Thread David Crossley
Leo Simons wrote:
[snip]
 ... It also looks like there's a
 sizeable amount of stuff from the forrest people that might be able to
 shrink a little.

Not really. I had already trimmed it down as much as possible.

I gather from watching the build-up to the upcoming Infrathon
that the scheduled extra resources for brutus, and the other
IBM-donated machines, is not likely to happen. Is there an
alternative plan to get more disk space?

--David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]