[EMAIL PROTECTED]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 86 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- ant-contrib :  Useful little Ant tasks
- ant-contrib-test :  Useful little Ant tasks
- antbook-diary-core :  Examples to go with Java Development with Ant
- apollo :  Apollo Project
- authx-example :  Apache Authentication and Authorization Framework
- authx-script :  Apache Authentication and Authorization Framework
- cargo :  Cargo provides a Java API to manipulate Java Containers
- commons-codec :  Commons Encoding/Decoding Package
- commons-configuration :  Jakarta commons
- commons-httpclient :  HTTP Client Library
- commons-httpclient-2.0-branch :  HTTP Client Library
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jmx :  Commons Jelly
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- commons-transaction :  Commons Identifier Package
- commons-vfs :  Jakarta commons
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- excalibur-fortress-bean :  Repository of reusable components.
- excalibur-fortress-container-impl :  Repository of reusable components.
- excalibur-fortress-container-test :  Repository of reusable components.
- excalibur-fortress-examples :  Repository of reusable components.
- excalibur-fortress-migration :  Repository of reusable components.
- excalibur-fortress-platform :  Repository of reusable components.
- excalibur-fortress-testcase :  Repository of reusable components.
- excalibur-monitor :  Repository of reusable components.
- excalibur-sourceresolve :  Repository of reusable components.
- excalibur-xmlutil :  Repository of reusable components.
- forrest-whiteboard-forrestdoc :  Apache Forrest is an XML 
standards-oriented documentation fr...
- forrest-whiteboard-forrestdoc-autotest :  Apache Forrest is an XML 
standards-oriented documentation fr...
- fulcrum-cache :  Services Framework
- fulcrum-configuration-impl :  Services Framework
- fulcrum-crypto :  Services Framework
- fulcrum-intake :  Services Framework
- fulcrum-parser :  Services Framework
- fulcrum-security-api :  Services Framework
- fulcrum-security-memory :  Services Framework
- fulcrum-security-nt :  Services Framework
- fulcrum-template :  Services Framework
- fulcrum-xmlrpc :  Services Framework
- geronimo :  Apache Geronimo, the J2EE server project of the Apache 
Softw...
- groovy :  New agile dynamic language using a Java-like syntax for the ...
- htmlunit :  A tool for testing web based applications
- invicta :  Open-source build management tool.
- jakarta-cactus-documentation :  Cactus Documentation
- jakarta-cactus-framework-12 :  Cactus Framework (J2EE 1.2)
- jakarta-cactus-framework-13 :  Cactus Framework (J2EE 1.3)
- jakarta-cactus-release-12 :  Unit test framework for server-side java code
- jakarta-cactus-release-13 :  Unit test framework for server-side java code
- jakarta-cactus-sample-jetty-13 :  Cactus Jetty Sample (J2EE 1.3)
- jakarta-cactus-sample-servlet-12 :  Cactus Servlet Sample (J2EE 1.2)
- jakarta-cactus-sample-servlet-13 :  Cactus Servlet Sample (J2EE 1.3)
- jakarta-jmeter-22-svn :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-jmeter-22-test :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-slide :  Content Management System based on WebDAV technology
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jetty :  Java HTTP Servlet Server
- jetty-plus :  Java HTTP Servlet Server
- jgroups :  A Reliable Multicast Communication Toolkit for Java
- logging-log4cxx-ant :  Apache log4cxx
- logging-log4cxx-ant-no_wchar_t :  Apache log4cxx
- logging-log4cxx-ant-static :  Apache log4cxx
- logging-log4j-chainsaw :  Chainsaw log viewer
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools
- muse :  Muse Project
- mx4j :  OpenSource implementation of a JMX agent
- mx4j-tools :  OpenSource implementation of a JMX agent
- mx4j-tools-from-packaged-jetty :  OpenSource implementation of a JMX agent
- myfaces :  JavaServer(tm) Faces implementation
- naming-management 

[EMAIL PROTECTED]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 86 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- ant-contrib :  Useful little Ant tasks
- ant-contrib-test :  Useful little Ant tasks
- antbook-diary-core :  Examples to go with Java Development with Ant
- apollo :  Apollo Project
- authx-example :  Apache Authentication and Authorization Framework
- authx-script :  Apache Authentication and Authorization Framework
- cargo :  Cargo provides a Java API to manipulate Java Containers
- commons-codec :  Commons Encoding/Decoding Package
- commons-configuration :  Jakarta commons
- commons-httpclient :  HTTP Client Library
- commons-httpclient-2.0-branch :  HTTP Client Library
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jmx :  Commons Jelly
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- commons-transaction :  Commons Identifier Package
- commons-vfs :  Jakarta commons
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- excalibur-fortress-bean :  Repository of reusable components.
- excalibur-fortress-container-impl :  Repository of reusable components.
- excalibur-fortress-container-test :  Repository of reusable components.
- excalibur-fortress-examples :  Repository of reusable components.
- excalibur-fortress-migration :  Repository of reusable components.
- excalibur-fortress-platform :  Repository of reusable components.
- excalibur-fortress-testcase :  Repository of reusable components.
- excalibur-monitor :  Repository of reusable components.
- excalibur-sourceresolve :  Repository of reusable components.
- excalibur-xmlutil :  Repository of reusable components.
- forrest-whiteboard-forrestdoc :  Apache Forrest is an XML 
standards-oriented documentation fr...
- forrest-whiteboard-forrestdoc-autotest :  Apache Forrest is an XML 
standards-oriented documentation fr...
- fulcrum-cache :  Services Framework
- fulcrum-configuration-impl :  Services Framework
- fulcrum-crypto :  Services Framework
- fulcrum-intake :  Services Framework
- fulcrum-parser :  Services Framework
- fulcrum-security-api :  Services Framework
- fulcrum-security-memory :  Services Framework
- fulcrum-security-nt :  Services Framework
- fulcrum-template :  Services Framework
- fulcrum-xmlrpc :  Services Framework
- geronimo :  Apache Geronimo, the J2EE server project of the Apache 
Softw...
- groovy :  New agile dynamic language using a Java-like syntax for the ...
- htmlunit :  A tool for testing web based applications
- invicta :  Open-source build management tool.
- jakarta-cactus-documentation :  Cactus Documentation
- jakarta-cactus-framework-12 :  Cactus Framework (J2EE 1.2)
- jakarta-cactus-framework-13 :  Cactus Framework (J2EE 1.3)
- jakarta-cactus-release-12 :  Unit test framework for server-side java code
- jakarta-cactus-release-13 :  Unit test framework for server-side java code
- jakarta-cactus-sample-jetty-13 :  Cactus Jetty Sample (J2EE 1.3)
- jakarta-cactus-sample-servlet-12 :  Cactus Servlet Sample (J2EE 1.2)
- jakarta-cactus-sample-servlet-13 :  Cactus Servlet Sample (J2EE 1.3)
- jakarta-jmeter-22-svn :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-jmeter-22-test :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-slide :  Content Management System based on WebDAV technology
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jetty :  Java HTTP Servlet Server
- jetty-plus :  Java HTTP Servlet Server
- jgroups :  A Reliable Multicast Communication Toolkit for Java
- logging-log4cxx-ant :  Apache log4cxx
- logging-log4cxx-ant-no_wchar_t :  Apache log4cxx
- logging-log4cxx-ant-static :  Apache log4cxx
- logging-log4j-chainsaw :  Chainsaw log viewer
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools
- muse :  Muse Project
- mx4j :  OpenSource implementation of a JMX agent
- mx4j-tools :  OpenSource implementation of a JMX agent
- mx4j-tools-from-packaged-jetty :  OpenSource implementation of a JMX agent
- myfaces :  JavaServer(tm) Faces implementation
- naming-management 

[EMAIL PROTECTED]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 86 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- ant-contrib :  Useful little Ant tasks
- ant-contrib-test :  Useful little Ant tasks
- antbook-diary-core :  Examples to go with Java Development with Ant
- apollo :  Apollo Project
- authx-example :  Apache Authentication and Authorization Framework
- authx-script :  Apache Authentication and Authorization Framework
- cargo :  Cargo provides a Java API to manipulate Java Containers
- commons-codec :  Commons Encoding/Decoding Package
- commons-configuration :  Jakarta commons
- commons-httpclient :  HTTP Client Library
- commons-httpclient-2.0-branch :  HTTP Client Library
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jmx :  Commons Jelly
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- commons-transaction :  Commons Identifier Package
- commons-vfs :  Jakarta commons
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- excalibur-fortress-bean :  Repository of reusable components.
- excalibur-fortress-container-impl :  Repository of reusable components.
- excalibur-fortress-container-test :  Repository of reusable components.
- excalibur-fortress-examples :  Repository of reusable components.
- excalibur-fortress-migration :  Repository of reusable components.
- excalibur-fortress-platform :  Repository of reusable components.
- excalibur-fortress-testcase :  Repository of reusable components.
- excalibur-monitor :  Repository of reusable components.
- excalibur-sourceresolve :  Repository of reusable components.
- excalibur-xmlutil :  Repository of reusable components.
- forrest-whiteboard-forrestdoc :  Apache Forrest is an XML 
standards-oriented documentation fr...
- forrest-whiteboard-forrestdoc-autotest :  Apache Forrest is an XML 
standards-oriented documentation fr...
- fulcrum-cache :  Services Framework
- fulcrum-configuration-impl :  Services Framework
- fulcrum-crypto :  Services Framework
- fulcrum-intake :  Services Framework
- fulcrum-parser :  Services Framework
- fulcrum-security-api :  Services Framework
- fulcrum-security-memory :  Services Framework
- fulcrum-security-nt :  Services Framework
- fulcrum-template :  Services Framework
- fulcrum-xmlrpc :  Services Framework
- geronimo :  Apache Geronimo, the J2EE server project of the Apache 
Softw...
- groovy :  New agile dynamic language using a Java-like syntax for the ...
- htmlunit :  A tool for testing web based applications
- invicta :  Open-source build management tool.
- jakarta-cactus-documentation :  Cactus Documentation
- jakarta-cactus-framework-12 :  Cactus Framework (J2EE 1.2)
- jakarta-cactus-framework-13 :  Cactus Framework (J2EE 1.3)
- jakarta-cactus-release-12 :  Unit test framework for server-side java code
- jakarta-cactus-release-13 :  Unit test framework for server-side java code
- jakarta-cactus-sample-jetty-13 :  Cactus Jetty Sample (J2EE 1.3)
- jakarta-cactus-sample-servlet-12 :  Cactus Servlet Sample (J2EE 1.2)
- jakarta-cactus-sample-servlet-13 :  Cactus Servlet Sample (J2EE 1.3)
- jakarta-jmeter-22-svn :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-jmeter-22-test :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-slide :  Content Management System based on WebDAV technology
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jetty :  Java HTTP Servlet Server
- jetty-plus :  Java HTTP Servlet Server
- jgroups :  A Reliable Multicast Communication Toolkit for Java
- logging-log4cxx-ant :  Apache log4cxx
- logging-log4cxx-ant-no_wchar_t :  Apache log4cxx
- logging-log4cxx-ant-static :  Apache log4cxx
- logging-log4j-chainsaw :  Chainsaw log viewer
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools
- muse :  Muse Project
- mx4j :  OpenSource implementation of a JMX agent
- mx4j-tools :  OpenSource implementation of a JMX agent
- mx4j-tools-from-packaged-jetty :  OpenSource implementation of a JMX agent
- myfaces :  JavaServer(tm) Faces implementation
- naming-management :  Apache Directory Naming Component
  

[EMAIL PROTECTED]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 86 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- ant-contrib :  Useful little Ant tasks
- ant-contrib-test :  Useful little Ant tasks
- antbook-diary-core :  Examples to go with Java Development with Ant
- apollo :  Apollo Project
- authx-example :  Apache Authentication and Authorization Framework
- authx-script :  Apache Authentication and Authorization Framework
- cargo :  Cargo provides a Java API to manipulate Java Containers
- commons-codec :  Commons Encoding/Decoding Package
- commons-configuration :  Jakarta commons
- commons-httpclient :  HTTP Client Library
- commons-httpclient-2.0-branch :  HTTP Client Library
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jmx :  Commons Jelly
- commons-jelly-tags-ojb :  Commons Jelly
- commons-jelly-tags-soap :  Commons Jelly
- commons-transaction :  Commons Identifier Package
- commons-vfs :  Jakarta commons
- db-ddlutils :  Easy-to-use component for working with Database Definition 
(...
- db-ojb :  ObjectRelationalBridge
- db-ojb-from-packages :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- excalibur-fortress-bean :  Repository of reusable components.
- excalibur-fortress-container-impl :  Repository of reusable components.
- excalibur-fortress-container-test :  Repository of reusable components.
- excalibur-fortress-examples :  Repository of reusable components.
- excalibur-fortress-migration :  Repository of reusable components.
- excalibur-fortress-platform :  Repository of reusable components.
- excalibur-fortress-testcase :  Repository of reusable components.
- excalibur-monitor :  Repository of reusable components.
- excalibur-sourceresolve :  Repository of reusable components.
- excalibur-xmlutil :  Repository of reusable components.
- forrest-whiteboard-forrestdoc :  Apache Forrest is an XML 
standards-oriented documentation fr...
- forrest-whiteboard-forrestdoc-autotest :  Apache Forrest is an XML 
standards-oriented documentation fr...
- fulcrum-cache :  Services Framework
- fulcrum-configuration-impl :  Services Framework
- fulcrum-crypto :  Services Framework
- fulcrum-intake :  Services Framework
- fulcrum-parser :  Services Framework
- fulcrum-security-api :  Services Framework
- fulcrum-security-memory :  Services Framework
- fulcrum-security-nt :  Services Framework
- fulcrum-template :  Services Framework
- fulcrum-xmlrpc :  Services Framework
- geronimo :  Apache Geronimo, the J2EE server project of the Apache 
Softw...
- groovy :  New agile dynamic language using a Java-like syntax for the ...
- htmlunit :  A tool for testing web based applications
- invicta :  Open-source build management tool.
- jakarta-cactus-documentation :  Cactus Documentation
- jakarta-cactus-framework-12 :  Cactus Framework (J2EE 1.2)
- jakarta-cactus-framework-13 :  Cactus Framework (J2EE 1.3)
- jakarta-cactus-release-12 :  Unit test framework for server-side java code
- jakarta-cactus-release-13 :  Unit test framework for server-side java code
- jakarta-cactus-sample-jetty-13 :  Cactus Jetty Sample (J2EE 1.3)
- jakarta-cactus-sample-servlet-12 :  Cactus Servlet Sample (J2EE 1.2)
- jakarta-cactus-sample-servlet-13 :  Cactus Servlet Sample (J2EE 1.3)
- jakarta-jmeter-22-svn :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-jmeter-22-test :  Pure Java load testing and performance 
measurement tool.
   ...
- jakarta-slide :  Content Management System based on WebDAV technology
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-jcs :  Cache
- jetty :  Java HTTP Servlet Server
- jetty-plus :  Java HTTP Servlet Server
- jgroups :  A Reliable Multicast Communication Toolkit for Java
- logging-log4cxx-ant :  Apache log4cxx
- logging-log4cxx-ant-no_wchar_t :  Apache log4cxx
- logging-log4cxx-ant-static :  Apache log4cxx
- logging-log4j-chainsaw :  Chainsaw log viewer
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools
- muse :  Muse Project
- mx4j :  OpenSource implementation of a JMX agent
- mx4j-tools :  OpenSource implementation of a JMX agent
- mx4j-tools-from-packaged-jetty :  OpenSource implementation of a JMX agent
- myfaces :  JavaServer(tm) Faces implementation
- naming-management :  Apache Directory Naming Component
  

Re: [JEXL] Validate plugin Uberspec approach

[Tim OBrien]

So, in a class like ASTArrayAccess, you are talking about changing a call like 
this:

VelPropertyGet vg = Introspector.getUberspect().getPropertyGet(o, s, DUMMY);

To something like,

VelPropertyGet vg = jexlContext.getIntrospector().getUberspect()

Seems reasonable, but you might want to preserve the default static instance of 
Uberspect on
Introspector for continuity.

Tim

--- [EMAIL PROTECTED] wrote:

 Hi,
 
 It looks like the simplest place to provide a plugin mechanism in JEXL is 
 via the JexlContext object. My reasoning is that this object is passed 
 along everywhere that evaluation occurs, and would allow two different 
 users of JEXL within the same JVM to use different Uberspec objects.
 
 I wouldn't mind comments from the current contributor/committers for JEXL.
 
 Thanks,
 Doug
 
 


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

Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)

[Tim OBrien]

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

   Having said that, teasing apart the packages is a good idea. IMO, we
   should introduce two new packages with this reorganization:
  
(i)  o.a.c.scxml.digester - For the SCXMLDigester and its static
   inner classes (pulling them out so they exist on their own)
(ii) o.a.c.scxml.test - For the Standalone classes, StandaloneUtils
   and SCXMLSerializer. This clarifies the intent of the serializer and
   command-line tools much better, IMO.
  
 snap/
 
 Umm, any comments on this new test package from the command-line
 testing classes? Unless you scream, I might go ahead with this. I
 sometimes feel they (Standalone/StandaloneUtils classes) might be
 muddying up their current packages.
 

No objections. +1

 
   How does that sound?
  
   I'm not sure if you asked this question ;-) ... but the SCXMLDigester
   does two step processing because:
  
* As the SAX parser is throwing element start, end notifications etc.
   the Digester creates the object model the best it can
  
 
  Alright, I'm +1 for us attempting to capture this in a series of .betwixt 
  files in the model
  package and leveraging BeanReader (which is essentially just creating 
  Digester rules from the
  mapping).  I think this would make it easier to say support other attribute 
  from the draft as
  needed (like delay).
 
 snap/
 
 Didn't catch the delay comment, but Betwixt sounds good if you're all
 for it. Is it your intent to get something in there to get us started?
 That would be great.
 
 Does it have to be in the model package? Maybe we should have a
 separate io package (even child of model)? Though I don't want to
 spend too much time on the names here, seems like it really might be
 useful to separate the model itself from the read/write business, IMO.
 

It would help if the .betwixt files were in model package, but I do agree that 
any class that deal
with reading/writing should be in an io package.  Don't get too caught up on 
that couplng just yet
until you see it.

The delay comment was a reference to an attribute (i think on transition) from 
the working draft
that SCXML doesn't yet support.  The point being that as SCXML comes to 
implement more and more of
the specification, what you are really doing is just adding more properties to 
the model, I think
this would be easier to capture if we didn't rely on hand-craft Digester rules 
and just used
Betwixt.


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

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Tim OBrien]

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

 On 1/18/06, Tim OBrien [EMAIL PROTECTED] wrote:
 
 
  --- Rahul Akolkar [EMAIL PROTECTED] wrote:
 
   On 1/14/06, Tim OBrien [EMAIL PROTECTED] wrote:
   snip/
2. Decouple Execution Context from the SCXML Model
   
  snip/
 
   Most of your observations are correct. We need effective cloneability
   and/or decoupling, re-parsing is a waste. If you have any ideas, do
   let me know. I'll spend some time on this during the rest of the week,
   primarily just starting a new thread here, will clip the email length
   in the next posts.
  
 
  Created a place holder issue for the task of identifying the appropriate 
  way to do this:
  http://issues.apache.org/bugzilla/show_bug.cgi?id=38311
 
  Do you want to take a stab at this?  I had some ideas about the semantic 
  impl, should we both
 try
  out some ideas independently in two different branches and then see what 
  bubbles out of
  independent effort?
 
 snip/
 
 I will take a stab at this in the upcoming week or two, will post
 something here when I get a chance to think some more about it. My
 initial thoughts are not using Cloneable, rather having the SCXML
 document read into a factory-style class, which can churn out
 o.a.c.scxml.model.SCXML objects. WDYT? You're ofcourse welcome to try
 an approach of your choice.
 
 sidebarI just remembered one of your earlier comments about State's
 not having a Context, but it appears there may soon be such an
 association, lets wait on the next Working Draft for that./sidebar
 

Even if a state is associated with a context it doesn't necessary mean that 
there needs to be a
relationship with an actual context item.

I guess this is a case of wellwouldn't it be helpful to be able to 
participate in that
Working Group.  :-)

The thing that I think is important for the SCXML working group to know is that 
for some
applications to be feasible a state machine must be efficient, not tied to 
execution context and
able to be shared at runtime by possibly thousands of instances.  Maybe 
putting it in Voice
terms might make it more relevant to that specific working group, if I'm trying 
to model the state
of ten thousand simultaneous conversations, I'd start to care whether or not 
I'd would have to
replicate the entire model or representation of the state machine.  

   This actually was one of the things I had in mind between sandbox
   graduation and release.
  
 
  And, this is I guess one of the central issues with releasing scxml into 
  commons (again, not
 that
  I disagree with it being in the commons).  Althogh I think there is some 
  room for flexibility
  after a release, commons components are limited by the fact that we haveto 
  try to maintain
  compatibility between major releases.
 
 snap/
 
 I understand those constraints.
 
 
  Becuase of this, I think that the public interface of scxml needs extra 
  scrutiny before a
 release
 snip/
 
 Its welcome, and I'm thankful to anyone who offers the code such scrutiny.
 
 
  (and to me the 1.0 release happens at the same tie as promotion).
 
 snap/
 
 This is where there can be two schools of thought:
 
 School of Thought #1:
 Promotion == 1.0 (I was subscribed to this one in Taglibs, for
 example, RDC went for 1.0 and promotion together)
 
 School of Thought #2:
 Promotion -- Bunch of RCs *and* potential changes -- 1.0
 (gives earlier indication that development efforts are not going to /dev/null)
 

I prefer #1 because it provides some motivation for interested developers.  To 
me it ensure that
there is a community around something before promotion rather than jsut 
promoting something that
would ultimate get abandoned (like feedparser which IMO was promoted without 
much scrutiny).

But, that's neither here nor there, I don't think scxml will have an issue 
getting to a 1.0 release.

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

Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)

[Tim OBrien]

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

 On 1/19/06, Peter Costa [EMAIL PROTECTED] wrote:
  I am new to the list
 snip/
  and would like to get involved in
  this project.
 snap/
 
 We're always looking for help :-)
 
 
  I was wondering if you could tell me
  where to get more information SCXML other than the
  website.  Are there any other docs out there?  I would
  like to know what you want me to do to get started on
  this project.
 

Understand this Working Draft from the W3C: 
http://www.w3.org/TR/2005/WD-scxml-20050705/

Probably the most valuable thing you could do at the moment would be to give 
some scrutiny to what
Rahul has come up with and understand SCXML.



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

Re: [scxml] a few observations, issues before release

[Tim OBrien]

Rahul, my emails are a tad long, eh?  Apologies in advance.

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

  3. Is SCXML appropriate for Commons?
 
  Commons SCXML might not be appropriate for Jakarta Commons.  See the recent 
  discussion on
 general@
  about componentizing different parts of Jakarta.  I'm not going to fight 
  this one because I
 think
  we're in a time of transition, but commons-scxml might ultimately benefit 
  from producing a
 number
  of separate artifacts.  scxml, scxml-faces, scxml-shale, etc.
 
 snip/
 
 Yup, seen that thread. However, IMO, moving SCXML *again* will amount
 to handing off what I will call a death by Commons to this
 component. We moved the codebase from Taglibs because I completely
 agreed with Martin's (martinc) suggestion at the time that this code
 is useful beyond its first usecase in Taglibs. Very few of those who
 supported the RDC development and release are present in Commons which
 means we started mostly from scratch in terms of developer community.
 Now we're at a point in Commons where the veto vote from Martin (mvdb)
 however acknowledges the sustained development effort around Commons
 SCXML. The component will lose this history once again if we go
 elsewhere. ATM, IMO, Commons is the best place for this implementation
 to live in Jakarta (or Apache even).
 

Understood.   Let's just acknowledge that if scxml is a successful component, 
and if it
experiences the level of interest I think it warrants, it could very well go 
the route of
httpclient.  

At the moment, it is a simple, narrow component focused on scxml.   I think it 
would be wise to
think about the long term.  Jakarta is going to undergo some transitions over 
the next year (see
general@ thread from last week), and during that transition we should put a 
flag on scxml as one
of the components that we need to think about as being qualitatively different 
from something like
Commons Lang.

But, short-term, promotion to proper makes sense.

snip/

You are right about Jakarta state transitions not being nearly as clean as an 
ideal state machine.
 

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

Re: [SCXML] Decoupling Execution Context from the SCXML Model (WAS: [scxml] a few observations, issues before release)

[Tim OBrien]

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

 On 1/14/06, Tim OBrien [EMAIL PROTECTED] wrote:
 snip/
  2. Decouple Execution Context from the SCXML Model
 
snip/
 
 Most of your observations are correct. We need effective cloneability
 and/or decoupling, re-parsing is a waste. If you have any ideas, do
 let me know. I'll spend some time on this during the rest of the week,
 primarily just starting a new thread here, will clip the email length
 in the next posts.
 

Created a place holder issue for the task of identifying the appropriate way to 
do this:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38311

Do you want to take a stab at this?  I had some ideas about the semantic impl, 
should we both try
out some ideas independently in two different branches and then see what 
bubbles out of
independent effort?

 This actually was one of the things I had in mind between sandbox
 graduation and release.
 

And, this is I guess one of the central issues with releasing scxml into 
commons (again, not that
I disagree with it being in the commons).  Althogh I think there is some room 
for flexibility
after a release, commons components are limited by the fact that we haveto try 
to maintain
compatibility between major releases.  

Becuase of this, I think that the public interface of scxml needs extra 
scrutiny before a release
(and to me the 1.0 release happens at the same tie as promotion).

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


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

Re: [SCXML] SCXMLSerializer and package reorganization (WAS: [scxml] a few observations, issues before release)

[Tim OBrien]

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

 On 1/14/06, Tim OBrien [EMAIL PROTECTED] wrote:
 snip/
trim/
 snap/
 
 The reasons the SCXMLserializer exists are somewhat historic, though
 it has utility from a testing/trying out POV. As the Javadoc for the
 class states:
 
 quoteUsed primarily for testing, debugging and visual verification./quote
 
 It is easier to visualize the object model by just dumping it to
 System.out and the Standalone classes ...
 
 http://jakarta.apache.org/commons/sandbox/scxml/api-notes/testing-standalone.html
 
 ... serve as simple tools to just try things out at the
 command-line, and are the ones that use the SCXMLSerializer.
 
 The SCXMLSerializer does *not* serve any purpose as far as the SCXML
 engine / SCXMLExecutor is concerned, since state charts model
 behavior and the SCXML documents themselves can be considered as
 immutable, and there is never any need to serialize them or write them
 out (other than reasons specified in Javadocs).
 
 I have never done any appreciable amount of betwixt, but I have used
 digester. That is probably one of the most prominent reasons why SCXML
 uses digester. The other being I consider this to be primarily a
 directional XML -- Java object model mapping, where the other
 direction is not as significant. I'm willing to spend some time in the
 research if you're confident that betwixt is a good candidate here.
 Specifically-
 
  * We need to reading in arbitrary document fragments (digester has a
 NodeCreateRule)
  * Reading and splicing in external documents refered to via src
 attributes (you've already answered this above)
  * Mapping to the existing Commons SCXML object model (the
 o.a.c.scxml.model package)
  * IMO, we're not really interested in writing as much
 

Betwixt leverages the Digester, in fact, the BeanReader is a subclass of the 
Digester.  If you
capture the mapping from SCXML to the State model objects, in .betwixt files, 
you are essentially
using the Betwixt framework as a short-hand for the digester rules.  You can 
handle mapping to
existing commons SCXML objects right now with Betwixt.

I think that you shouldn't discount the important of writing, I think that it 
is something that
could come in very handy.

 Having said that, teasing apart the packages is a good idea. IMO, we
 should introduce two new packages with this reorganization:
 
  (i)  o.a.c.scxml.digester - For the SCXMLDigester and its static
 inner classes (pulling them out so they exist on their own)
  (ii) o.a.c.scxml.test - For the Standalone classes, StandaloneUtils
 and SCXMLSerializer. This clarifies the intent of the serializer and
 command-line tools much better, IMO.
 
 How does that sound?
 
 I'm not sure if you asked this question ;-) ... but the SCXMLDigester
 does two step processing because:
 
  * As the SAX parser is throwing element start, end notifications etc.
 the Digester creates the object model the best it can
 

Alright, I'm +1 for us attempting to capture this in a series of .betwixt files 
in the model
package and leveraging BeanReader (which is essentially just creating Digester 
rules from the
mapping).  I think this would make it easier to say support other attribute 
from the draft as
needed (like delay).

  * The post-processing picks up the loose ends. For example, for this snippet:
 
transition ...
 target next=foo /
/transition
 
the transition target (state/history/parallel) with id foo may
 appear later in the stream of parsing, and thus, can be only linked
 into the transitions graph in a post-processing stage.


I think that the post-process would also include identifying external src 
attributes and invoking
another BeanReader, recursion...
 
  * I've seen similar Digester usages not do the post-processing and
 throw IllegalArgumentException's at run-time if target is not found,
 but since we have all the information we need immediately after
 parsing the document to verify those bits, I'm of the opinion that the
 transitions graph should be verified right then and there.
 
 I'm inclined to leave this bit in the o.a.c.scxml.digester package,
 maybe we can call it something other than digester if you have
 suggestions?
 

I think it would be wise to take references to Digester out of the class name 
entirely. 
SCXMLReader and SCXMLWriter?  SCXMLFactory, I'm not a big fan of naming debates 
(bricks vs.
WebComponents), but marrying this component to Digester in the class name 
might be more
confusing to the population of users who will just want to read in an SCXML 
document.

Is this more branch experimentation work?

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


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

RE: [scxml] compliance with SCXML Working Draft

[Tim OBrien]

Good to hear that a stricter definition is on the way, I noticed that section 
5.1 had constraints
on attributes, but I didn't see any in 3.1. Let me ask you another question 
while I've got your
attention, any plans to release an XML Schema for the SCXML standard? 

...this brings up another issue, I think it would be beneficial for the ASF to 
join the W3C, but
we're currently not a Member organization.  Is there mechanism by which 
interested committers
could get a window into the working group? 

Tim

--- Barnett, James [EMAIL PROTECTED] wrote:

 We hope to have a new working draft of the SCXML spec out soon (i.e. a
 week or two), which  will tighten up the syntactic definition.  The
 'initialstate' attribute will be required.  
 In general, for conformance issues, we will want to focus on the new
 draft, rather than the existing one.  (But the new draft will leave the
 semantics vague in a number of places - we hope to tighten them up in
 the following draft.)
 
 - Jim
 
 -Original Message-
 From: Tim OBrien [mailto:[EMAIL PROTECTED] 
 Sent: Saturday, January 14, 2006 10:23 AM
 To: commons-dev@jakarta.apache.org
 Subject: [scxml] compliance with SCXML Working Draft
 
 I'm trying to use SCXMLDigester to read an SCXML file without an
 initialstate attribute defined
 on the scxml document element.  Doing so throws a SEVERE: No SCXML
 child state with ID null
 found; illegal initialstate for SCXML document
 
 The Working Draft
 (http://www.w3.org/TR/2005/WD-scxml-20050705/#Semantics) doesn't specify
 whether
 or not the initialstate attribute is required, and from the examples in
 sections E1 and E2, SCXML
 documents without this attribute are presented.  I'm assuming that there
 can be state chart XML
 documents that do not specify an initial state until the draft is
 updated.
 
 updateSCXML in SCXMLDigester assumes that this attribute is present.
 Rahil, I propose that if the
 initialstate is not present this method shouldn't print an error message
 SEVERE, it should just
 skip setting the initialstate.  I believe that the default behavior
 works, but the error message
 is misleading.
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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

Re: [RESULT][VOTE] Promote SCXML to Proper

[Tim OBrien]

Add mine to the mix just for the record

+0 at this time, I don't anticipate this not making it out of sandbox, but I'd 
like to help solve
the only one committer issue before we promote.

...and I just have some questions about committing to this public contract  in 
a 1.0 release.  

--- Rahul Akolkar [EMAIL PROTECTED] wrote:

 There was a veto against this vote, and hence, this vote has failed.
 
 -1 mvdb  (PMC, hence veto -- primary reason: lack of support from
 other Commons' developers)
 +1 rahul (Commons committer)
 
 No other votes.
 
 -Rahul
 
 
 On 1/12/06, Rahul Akolkar [EMAIL PROTECTED] wrote:
  It is time for a promotion vote for Commons SCXML [1], whose initial
  project proposal is archived here [2].
 
  A proposal for the promotion of this component that contained a
  release plan [3], was posted about 3 weeks ago, and that thread is
  archived here (amongst other places):
 
  http://marc.theaimsgroup.com/?t=11352205513r=1w=2
 
  Lets move SCXML to Proper. This vote will remain open for a minimum of 72 
  hours.
 
  --
  [ ] +1 Move SCXML to Commons Proper
  [ ] +0 I am fine with this move
  [ ] -0 I am not too keen, because ...
  [ ] -1 I am against this move, because ...
  --
 
  -Rahul
 
  [1] http://jakarta.apache.org/commons/sandbox/scxml/
  [2] 
  http://svn.apache.org/repos/asf/jakarta/commons/sandbox/scxml/trunk/PROPOSAL.html
  [3] http://wiki.apache.org/jakarta-commons/SCXML/1.0.0ReleasePlan
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 


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

[scxml] compliance with SCXML Working Draft

[Tim OBrien]

I'm trying to use SCXMLDigester to read an SCXML file without an initialstate 
attribute defined
on the scxml document element.  Doing so throws a SEVERE: No SCXML child 
state with ID null
found; illegal initialstate for SCXML document

The Working Draft (http://www.w3.org/TR/2005/WD-scxml-20050705/#Semantics) 
doesn't specify whether
or not the initialstate attribute is required, and from the examples in 
sections E1 and E2, SCXML
documents without this attribute are presented.  I'm assuming that there can be 
state chart XML
documents that do not specify an initial state until the draft is updated.

updateSCXML in SCXMLDigester assumes that this attribute is present.  Rahil, I 
propose that if the
initialstate is not present this method shouldn't print an error message 
SEVERE, it should just
skip setting the initialstate.  I believe that the default behavior works, but 
the error message
is misleading.




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

Re: [id] Review before 1.0 (Summary)

[Tim OBrien]

Good summary, comments inline...

--- Jörg Schaible [EMAIL PROTECTED] wrote:

 4/ Copied c-codec classes in official API
 
 To remove a dependency to c-codec the digest and hex utilities have been
 copied to c-id, but they are now publicly available in the o.a.c.id
 namespace.
 
 Martin already proposed to move them to a package o.a.c.id.internal and
 provide an appropriate package.html. As alternative we could try to make
 them package accessible only and remove any unused functionality (they have
 bad coverage reports because we only use view methods).

+1 with moving into an internal package with a package.html,  

Of two minds on the coverage issue, one one hand the class is well tested over 
in codec so you
could just trust that the class is well tested.  But, could you also just copy 
the unit tests from
c-codec and add them into c-id.  I don't see a huge problem there as long as 
there is sufficient
notice in the classes to the effect of DON'T CHANGE ME HERE, CHANGE ME IN 
COMMONS CODEC.



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

Re: [id] Review before 1.0 (Summary)

[Tim OBrien]

--- Jörg Schaible [EMAIL PROTECTED] wrote:

 Hi Tim,
 
 Tim OBrien wrote:
 
  Good summary, comments inline...
  
  --- Jörg Schaible [EMAIL PROTECTED] wrote:
  
  4/ Copied c-codec classes in official API
  
  To remove a dependency to c-codec the digest and hex utilities have been
  copied to c-id, but they are now publicly available in the o.a.c.id
  namespace.
  
  Martin already proposed to move them to a package o.a.c.id.internal and
  provide an appropriate package.html. As alternative we could try to make
  them package accessible only and remove any unused functionality (they
  have bad coverage reports because we only use view methods).
  
  +1 with moving into an internal package with a package.html,
  
  Of two minds on the coverage issue, one one hand the class is well tested
  over in codec so you
  could just trust that the class is well tested.  But, could you also just
  copy the unit tests from
  c-codec and add them into c-id.  I don't see a huge problem there as long
  as there is sufficient notice in the classes to the effect of DON'T
  CHANGE ME HERE, CHANGE ME IN COMMONS CODEC.
 
 If you remove the unused code, you have no tests, but coverage :)
 

Definitely, I see the point, I was just concerned that you might be removing 
something that might
eventually be needed, but if you are covering c-id code you know exactly what 
is needed and what
isn't.  

 Also it is much less encouraging for people to use these classes, if you
 state that you have only a partial copy of the original ...
 

Definitely.

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


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

[scxml] a few observations, issues before release

[Tim OBrien]

I'm interested in the SCXML codebase, but before I could vote +1 for promotion, 
I'm generally
thinking that the following issues need to be discussed.  I apologize if this 
is blocking RDC.

1. SCXMLSerializer 

Right now the code to serialize an SCXML object is a Visitor pattern that 
constructs XML using a
series of StringBuffers.  The code to read this XML document alrady uses a 
straightforward set of
Digester rules and the project already depends on commons-digester.

*Alternative: Add a dependency to commons-betwixt, map the model package to 
XML.  Instead of
writing Digester rules for reading and constructing Strings for writing, use 
the betwixt mapping
files as a single point of translation.

The current SCXMLDigester isn't trivial by any means, but I think it would be 
easy to implement
the external source rule.  The current SCXMLDigester plays two roles, first it 
sets up the
Digester rules and Digests the XML, but it also does a bit of post-processing 
in updateSCXML.  I
think the component would be well served to separate everything that has to do 
with serialization
to/from XML into a separate package and to move some of this postProcess that 
happens in
updateSCXML somewhere else.

2. Decouple Execution Context from the SCXML Model

Right now, the Context passed into the class that parses the XML and creates 
the SCXML object is
the global execution context.  You pass in a JexlContext when you are parsing 
the SCXML model, it
is assigned to all of the State objects.

So, bear with me, assume I have a SCXML document that represents the valid 
states of a stopwatch
(ready, running, paused, stopped).  The SCXML models the watch in a way similar 
to the microwave
sample in the Working Draft, it uses a reference to a timer variable.  To do 
this with the
current implementation of SCXML, I would need to do the following twice 
(assuming a JexlContext):

  a. Create a JexlContext
  b. Populate the JexlContext with the appropriate variables
  c. Call SCXMLDigester passing in the JexlEvaluator and the JexlContext I want 
to execute this
state machine with
  d. Create an instance of SCXMLExecutor, pass it the SCXML from step c.

For each watch I need to model in this application, the implementation forces 
me to parse that
SCXML document with Digester every time I want to model a separate StopWatch.  
In the application
I'm interested in using this in, hundreds of documents in a content management 
system are going to
be modeled as individual state machines, I would hate to have to parse an SCXML 
file for each
individual document.

* Alternative: Provide a mechanism that allows you to clone an SCXML  instance 
so that you can
create a separate SCXMLExecutor that can model the same statemachine with an 
isolated Context.

* Better Alternative: States do not have a context.  Take the context 
property off of the State
and change executeActionList in SCXMLSemanticsImpl to get the Context from the 
Executor.  
Likewise, Transitions do not have a notificationRegistry, take that property 
off of a transition
and just have the SCXMLSemanticsImpl get the notificationRegistry from the 
Executor.

I don't think this is a terribly difficult idea, and decoupling the description 
of the FSM from
the execution state, would also make it much easier to persist either one.  

3. Is SCXML appropriate for Commons? 

Commons SCXML might not be appropriate for Jakarta Commons.  See the recent 
discussion on general@
about componentizing different parts of Jakarta.  I'm not going to fight this 
one because I think
we're in a time of transition, but commons-scxml might ultimately benefit from 
producing a number
of separate artifacts.  scxml, scxml-faces, scxml-shale, etc.

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

Re: [codec] invalid source tarball on www.apache.org/dist

[Tim OBrien]

--- Henri Yandell [EMAIL PROTECTED] wrote:

 On 1/7/06, Tim O'Brien [EMAIL PROTECTED]
 wrote:
  This file
 
 

http://www.apache.org/dist/jakarta/commons/codec/source/commons-codec-1.3-src.tar.gz
 
  doesn't have the appropriate commons-codec-1.3/
 directory in front of each
  entry.  When you unpack it in a directory, it just
 throws the contents of the
  source distro into the current directory.
 
  So, to fix this, I propose re-releasing this one
 file.  I wasn't the release
  manager for the 1.3 release, but I'd be happy
 enough to repackage just this
  release from source, sign and seal it.
 
  Does anyone have any objections to replacing the
 1.3 source release with a file
  that follows the convention?
 
 My vote is to just repackage the existing tar.gz; or
 even better,
 unzip the .zip and tar.gz it. Basically to modify
 the package in situ
 and not to release from source.
 

Alright, it is done.  But, I didn't sign it.  I'll
ping Gary to resign that jar when he has a chance.


 Hen
 

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


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

[EMAIL PROTECTED]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-codec :  Commons Encoding/Decoding Package


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-codec-07062005.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Circular Dependency with ant.
 -ERROR- Circular Dependency with xml-xerces.
 -ERROR- Circular Dependency with xml-apis.
 -ERROR- Circular Dependency with junit.
 -DEBUG- Extracted fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 35331107062005, vmgump.apache.org:vmgump-public:35331107062005
Gump E-mail Identifier (unique within run) #20.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

[EMAIL PROTECTED]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-codec :  Commons Encoding/Decoding Package


Full details are available at:

http://vmgump.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-codec-07062005.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Circular Dependency with ant.
 -ERROR- Circular Dependency with xml-xerces.
 -ERROR- Circular Dependency with xml-apis.
 -ERROR- Circular Dependency with junit.
 -DEBUG- Extracted fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 35331107062005, vmgump.apache.org:vmgump-public:35331107062005
Gump E-mail Identifier (unique within run) #20.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

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

[GUMP@brutus]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Synchronize Failed'.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-codec-28012005.jar] identifier set to project name
 -INFO- Failed with reason synchronize failed
 -DEBUG- Extracted fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 2328012005, brutus:brutus-public:2328012005
Gump E-mail Identifier (unique within run) #17.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

[GUMP@brutus]: Project commons-codec (in module jakarta-commons) success

[Tim OBrien]

To whom it may satisfy...

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 commons-codec *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-codec-06122004.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
Work ended in a state of : Success
Elapsed: 12 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=06122004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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
-
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/test-reports

static:
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/conf

compile:
[javac] Compiling 24 source files to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes
 [copy] Copying 6 files to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes

javadoc:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/docs
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/docs/api
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.commons.codec...
  [javadoc] Loading source files for package org.apache.commons.codec.binary...
  [javadoc] Loading source files for package org.apache.commons.codec.digest...
  [javadoc] Loading source files for package 
org.apache.commons.codec.language...
  [javadoc] Loading source files for package org.apache.commons.codec.net...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.4.2_05
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] Generating 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/docs/api/stylesheet.css...
  [javadoc] 2 warnings

dist:
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist

init:
 [echo]  commons-codec 06122004 

prepare:

static:

compile:

jar:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes/META-INF
  [jar] Building jar: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/commons-codec-06122004.jar

BUILD SUCCESSFUL
Total time: 11 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: 

[GUMP@stormcrow]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Configuration 
Failed'.
For reference only, the following projects are affected by this:
- commons-codec :  Commons Encoding/Decoding Package


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-codec-09112004.jar] identifier set to project name
 -INFO- Failed with reason configuration failed
 -ERROR- Bad Dependency. Project: junit unknown to *this* workspace
 -INFO- Failed to extract fallback artifacts from Gump Repository

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 10301809112004, stormcrow:brutus-public:10301809112004
Gump E-mail Identifier (unique within run) #15.

--
Apache Gump
http://gump.apache.org/ [Instance: stormcrow]

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

[GUMP@stormcrow]: Project commons-codec (in module jakarta-commons) success

[Tim OBrien]

To whom it may satisfy...

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 commons-codec *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-codec-10112004.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
Work ended in a state of : Success
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=10112004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH: 
/usr/java/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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
-
[mkdir] Created dir: 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/target/test-reports

static:
 [copy] Copying 1 file to 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/target/conf

compile:
[javac] Compiling 24 source files to 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/target/classes
 [copy] Copying 6 files to 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/target/classes

javadoc:
[mkdir] Created dir: 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist
[mkdir] Created dir: 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist/docs
[mkdir] Created dir: 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist/docs/api
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.commons.codec...
  [javadoc] Loading source files for package org.apache.commons.codec.binary...
  [javadoc] Loading source files for package org.apache.commons.codec.digest...
  [javadoc] Loading source files for package 
org.apache.commons.codec.language...
  [javadoc] Loading source files for package org.apache.commons.codec.net...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.4.2_04
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] Generating 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist/docs/api/stylesheet.css...
  [javadoc] 2 warnings

dist:
 [copy] Copying 1 file to 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist
 [copy] Copying 1 file to 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist

init:
 [echo]  commons-codec 10112004 

prepare:

static:

compile:

jar:
[mkdir] Created dir: 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying 1 file to 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
  [jar] Building jar: 
/home/gump/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-10112004.jar

BUILD SUCCESSFUL
Total time: 5 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: 

[GUMP@brutus]: Project commons-codec (in module jakarta-commons) failed

[Tim OBrien]

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 commons-codec has an issue affecting its community integration.
This issue affects 7 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-codec :  Commons Encoding/Decoding Package
- commons-httpclient :  HTTP Client Library
- commons-httpclient-2.0-branch :  HTTP Client Library
- commons-id :  Commons Identifier Package
- commons-jelly-tags-http :  These Jelly tags provide a simple XML syntax for 
HttpClient.
- commons-jelly-tags-jetty :  These are Jelly tags that can set up an in-process 
web serve...
- xmlrpc :  A Java implementation of XML-RPC


Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [commons-codec-03112004.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=03112004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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
-
Exception in thread main java.lang.NoClassDefFoundError: org/apache/tools/ant/Main
-

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 2203112004, brutus:brutus-public:2203112004
Gump E-mail Identifier (unique within run) #7.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

[GUMP@brutus]: Project commons-codec (in module jakarta-commons) success

[Tim OBrien]

To whom it may satisfy...

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 commons-codec *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [commons-codec-03112004.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
Work ended in a state of : Success
Elapsed: 13 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=03112004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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
-
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/test-reports

static:
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/conf

compile:
[javac] Compiling 24 source files to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes
 [copy] Copying 6 files to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes

javadoc:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/docs
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/docs/api
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.commons.codec...
  [javadoc] Loading source files for package org.apache.commons.codec.binary...
  [javadoc] Loading source files for package org.apache.commons.codec.digest...
  [javadoc] Loading source files for package org.apache.commons.codec.language...
  [javadoc] Loading source files for package org.apache.commons.codec.net...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.4.2_05
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] Generating 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/docs/api/stylesheet.css...
  [javadoc] 2 warnings

dist:
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist

init:
 [echo]  commons-codec 03112004 

prepare:

static:

compile:

jar:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying 1 file to 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/target/classes/META-INF
  [jar] Building jar: 
/home/gump/workspaces2/public/workspace/jakarta-commons/codec/dist/commons-codec-03112004.jar

BUILD SUCCESSFUL
Total time: 11 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: 

[GUMP@brutus]: Project commons-codec (in module jakarta-commons) success

[Tim OBrien]

To whom it may satisfy...

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 commons-codec *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [commons-codec-16102004.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
Work ended in a state of : Success
Elapsed: 7 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=16102004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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
-
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-reports

static:
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/conf

compile:
[javac] Compiling 24 source files to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes
 [copy] Copying 6 files to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes

javadoc:
[mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons/codec/dist
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/docs
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/docs/api
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.commons.codec...
  [javadoc] Loading source files for package org.apache.commons.codec.binary...
  [javadoc] Loading source files for package org.apache.commons.codec.digest...
  [javadoc] Loading source files for package org.apache.commons.codec.language...
  [javadoc] Loading source files for package org.apache.commons.codec.net...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.4.2_05
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] Generating 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/docs/api/stylesheet.css...
  [javadoc] 2 warnings

dist:
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist

init:
 [echo]  commons-codec 16102004 

prepare:

static:

compile:

jar:
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
  [jar] Building jar: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-16102004.jar

BUILD SUCCESSFUL
Total time: 7 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

[GUMP@brutus]: Project commons-codec (in module jakarta-commons) success

[Tim OBrien]

To whom it may satisfy...

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 commons-codec *no longer* has an issue.
The current state of this project is 'Success'.

Full details are available at:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [commons-codec-16102004.jar] identifier set to project name
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
Work ended in a state of : Success
Elapsed: 22 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=16102004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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
-
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-reports

static:
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/conf

compile:
[javac] Compiling 24 source files to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes
 [copy] Copying 6 files to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes

javadoc:
[mkdir] Created dir: /usr/local/gump/public/workspace/jakarta-commons/codec/dist
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/docs
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/docs/api
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.commons.codec...
  [javadoc] Loading source files for package org.apache.commons.codec.binary...
  [javadoc] Loading source files for package org.apache.commons.codec.digest...
  [javadoc] Loading source files for package org.apache.commons.codec.language...
  [javadoc] Loading source files for package org.apache.commons.codec.net...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.4.2_05
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] 
/usr/local/gump/public/workspace/jakarta-commons/codec/src/java/org/apache/commons/codec/binary/BinaryCodec.java:35:
 warning - @todo is an unknown tag.
  [javadoc] Generating 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/docs/api/stylesheet.css...
  [javadoc] 2 warnings

dist:
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist

init:
 [echo]  commons-codec 16102004 

prepare:

static:

compile:

jar:
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
  [jar] Building jar: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-16102004.jar

BUILD SUCCESSFUL
Total time: 21 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/rss.xml
- Atom: http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/atom.xml

[GUMP@brutus]: jakarta-commons/commons-codec success

[Tim OBrien]

To whom it may satisfy...

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

Project commons-codec *no longer* has an issue.
Project State : 'Success'

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [commons-codec-20040725.jar] identifier set to project name
 -INFO- Enable verbose output, due to 1 previous error(s).
 -INFO- No license on redistributable project with outputs.


The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/gump_work/build_jakarta-commons_commons-codec.html
Work Name: build_jakarta-commons_commons-codec (Type: Build)
State: Success
Elapsed: 8 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dcomponent.version=20040725 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons/codec]
CLASSPATH : 
/usr/local/j2sdk1.4.2_04/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes:/usr/local/gump/public/workspace/jakarta-commons/codec/target/test-classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.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-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-
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF
 [copy] Copying /usr/local/gump/public/workspace/jakarta-commons/LICENSE to 
/usr/local/gump/public/workspace/jakarta-commons/codec/target/classes/META-INF/LICENSE.txt
  [jar] Building jar: 
/usr/local/gump/public/workspace/jakarta-commons/codec/dist/commons-codec-20040725.jar
  [jar] adding directory META-INF/
  [jar] adding entry META-INF/MANIFEST.MF
  [jar] adding entry META-INF/LICENSE.txt
  [jar] adding directory org/
  [jar] adding directory org/apache/
  [jar] adding directory org/apache/commons/
  [jar] adding directory org/apache/commons/codec/
  [jar] adding entry org/apache/commons/codec/BinaryDecoder.class
  [jar] adding entry org/apache/commons/codec/BinaryEncoder.class
  [jar] adding entry org/apache/commons/codec/Decoder.class
  [jar] adding entry org/apache/commons/codec/DecoderException.class
  [jar] adding entry org/apache/commons/codec/Encoder.class
  [jar] adding entry org/apache/commons/codec/EncoderException.class
  [jar] adding entry org/apache/commons/codec/StringDecoder.class
  [jar] adding entry org/apache/commons/codec/StringEncoder.class
  [jar] adding entry org/apache/commons/codec/StringEncoderComparator.class
  [jar] adding directory org/apache/commons/codec/binary/
  [jar] adding entry org/apache/commons/codec/binary/Base64.class
  [jar] adding entry org/apache/commons/codec/binary/BinaryCodec.class
  [jar] adding entry org/apache/commons/codec/binary/Hex.class
  [jar] adding entry org/apache/commons/codec/binary/package.html
  [jar] adding directory org/apache/commons/codec/digest/
  [jar] adding entry org/apache/commons/codec/digest/DigestUtils.class
  [jar] adding entry org/apache/commons/codec/digest/package.html
  [jar] adding directory org/apache/commons/codec/language/
  [jar] adding entry 
org/apache/commons/codec/language/DoubleMetaphone$DoubleMetaphoneResult.class
  [jar] adding entry org/apache/commons/codec/language/DoubleMetaphone.class
  [jar] adding entry org/apache/commons/codec/language/Metaphone.class
  [jar] adding entry org/apache/commons/codec/language/RefinedSoundex.class
  [jar] adding entry org/apache/commons/codec/language/Soundex.class
  [jar] adding entry org/apache/commons/codec/language/SoundexUtils.class
  [jar] adding entry org/apache/commons/codec/language/package.html
  [jar] adding directory org/apache/commons/codec/net/
  [jar] adding entry org/apache/commons/codec/net/BCodec.class
  [jar] adding entry org/apache/commons/codec/net/QCodec.class
  [jar] adding entry 

[GUMP@gump]: jakarta-commons-codec-11/commons-codec-11 failed

[Tim OBrien]

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 folk at [EMAIL PROTECTED]

Project commons-codec-11 has an issue affecting its community integration.
Project State : 'Failed', Reason 'Build Failed'

Full details are available at:

/jakarta-commons-codec-11/commons-codec-11/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [commons-codec-20040617.jar] identifier set to project name
 -INFO- Enable verbose output, due to 1 previous error(s).
 -INFO- Failed with reason build failed
 -INFO- Enable debug output, due to build failure.


The following work was performed:
/jakarta-commons-codec-11/commons-codec-11/gump_work/build_jakarta-commons-codec-11_commons-codec-11.html
Work Name: build_jakarta-commons-codec-11_commons-codec-11 (Type: Build)
State: Failed
Elapsed: 1 sec
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/var/gump/ws/xml-xerces2/java/build/xercesImpl.jar:/var/gump/ws/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose -Dgump.merge=/gump/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=20040617 -f build.xml dist 
[Working Directory: /var/gump/ws/jakarta-commons-codec-11/codec]
CLASSPATH : 
/usr/java/j2sdk1.4.2_03/lib/tools.jar:/var/gump/ws/ant/dist/lib/ant-stylebook.jar:/var/gump/ws/ant/dist/lib/ant-jmf.jar:/var/gump/ws/ant/dist/lib/ant-swing.jar:/var/gump/ws/ant/dist/lib/ant-trax.jar:/var/gump/ws/ant/dist/lib/ant-junit.jar:/var/gump/ws/ant/dist/lib/ant-launcher.jar:/var/gump/ws/ant/dist/lib/ant-nodeps.jar:/var/gump/ws/ant/dist/lib/ant.jar:/var/gump/ws/dist/junit/junit.jar-
Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.
Apache Ant version 1.7alpha compiled on June 17 2004
Buildfile: build.xml does not exist!
Build failed
-




To subscribe to this information via syndicated feeds:
 RSS: /jakarta-commons-codec-11/commons-codec-11/rss.xml
 Atom: /jakarta-commons-codec-11/commons-codec-11/atom.xml


--
Produced by Gump 2.1.0-alpha-0001.
[Run (20040617 22:46:57, gump.try.sybase.com:gump.try:20040617 22:46:57)]
/index.html
/options.html

--
Apache Gump
http://gump.apache.org/ [Instance: gump.try.sybase.com]

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

[GUMP@gump]: jakarta-commons-codec-11/commons-codec-11 failed

[Tim OBrien]

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 folk at [EMAIL PROTECTED]

Project commons-codec-11 has an issue affecting its community integration.
Project State : 'Failed', Reason 'Build Failed'

Full details are available at:

/jakarta-commons-codec-11/commons-codec-11/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [commons-codec-20040617.jar] identifier set to project name
 -INFO- Enable verbose output, due to 1 previous error(s).
 -INFO- Failed with reason build failed
 -INFO- Enable debug output, due to build failure.


The following work was performed:
/jakarta-commons-codec-11/commons-codec-11/gump_work/build_jakarta-commons-codec-11_commons-codec-11.html
Work Name: build_jakarta-commons-codec-11_commons-codec-11 (Type: Build)
State: Failed
Elapsed: 1 sec
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/var/gump/ws/xml-xerces2/java/build/xercesImpl.jar:/var/gump/ws/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -verbose -Dgump.merge=/gump/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=20040617 -f build.xml dist 
[Working Directory: /var/gump/ws/jakarta-commons-codec-11/codec]
CLASSPATH : 
/usr/java/j2sdk1.4.2_03/lib/tools.jar:/var/gump/ws/ant/dist/lib/ant-stylebook.jar:/var/gump/ws/ant/dist/lib/ant-jmf.jar:/var/gump/ws/ant/dist/lib/ant-swing.jar:/var/gump/ws/ant/dist/lib/ant-trax.jar:/var/gump/ws/ant/dist/lib/ant-junit.jar:/var/gump/ws/ant/dist/lib/ant-launcher.jar:/var/gump/ws/ant/dist/lib/ant-nodeps.jar:/var/gump/ws/ant/dist/lib/ant.jar:/var/gump/ws/dist/junit/junit.jar-
Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed.
Apache Ant version 1.7alpha compiled on June 17 2004
Buildfile: build.xml does not exist!
Build failed
-




To subscribe to this information via syndicated feeds:
 RSS: /jakarta-commons-codec-11/commons-codec-11/rss.xml
 Atom: /jakarta-commons-codec-11/commons-codec-11/atom.xml


--
Produced by Gump 2.1.0-alpha-0001.
[Run (20040617 22:46:57, gump.try.sybase.com:gump.try:20040617 22:46:57)]
/index.html
/options.html

--
Apache Gump
http://gump.apache.org/ [Instance: gump.try.sybase.com]

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

[GUMP@brutus]: jakarta-commons-codec-11/commons-codec-11 failed

[Tim OBrien]

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 folk at [EMAIL PROTECTED]

Project commons-codec-11 has an issue affecting its community integration.
This issue affects 70 projects, and has been outstanding for 15 runs.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-linotype :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-php :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-fw :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slide :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-webdav :  Java XML Framework
- cocoon-block-woody :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- cocoon-lenya :  Content Management System
- commons-jelly-tags-ojb :  A variety of tags for working with the ObjectBridge 
persiste...
- db-ojb :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- jakarta-jetspeed :  Enterprise Information Portal
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-3 :  A servlet based framework.
- jakarta-turbine-flux :  Servlet based framework
- jakarta-turbine-fulcrum :  Services Framework
- jakarta-turbine-jcs :  Cache
- jakarta-turbine-jyve :  FAQ-O-Matic
- jakarta-turbine-orgami :  Your organizer friend
- jakarta-turbine-site :  Servlet based framework
- scarab :  Issue Tracking Built for the Ages
- test-ojb :  ObjectRelationalBridge
- ws-xmlrpc :  A Java implementation of XML-RPC
- xml-forrest :  Forrest is an XML standards-oriented project documentation f...
- xml-xindice :  native XML database


Full details are available at:


http://brutus.apache.org:8080/gump/jakarta-commons-codec-11/commons-codec-11/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [commons-codec-20040609.jar] identifier set to project name
 -INFO- Enable debug output, due to a sequence of 14 previous errors.
 -INFO- Failed with reason build failed


The following work was performed:
http://brutus.apache.org:8080/gump/jakarta-commons-codec-11/commons-codec-11/gump_work/build_jakarta-commons-codec-11_commons-codec-11.html
Work Name: build_jakarta-commons-codec-11_commons-codec-11 (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 4 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -debug 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dcomponent.version=20040609 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-codec-11]
CLASSPATH : 

[GUMP@brutus]: jakarta-commons-codec-11/commons-codec-11 failed

[Tim OBrien]

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 folk at [EMAIL PROTECTED]

Project commons-codec-11 has an issue affecting its community integration.
This issue affects 70 projects, and has been outstanding for 7 runs.
Project State : 'Failed', Reason 'Build Failed'
The following are affected:
- cocoon :  Java XML Framework
- cocoon-block-apples :  Java XML Framework
- cocoon-block-asciiart :  Java XML Framework
- cocoon-block-authentication-fw :  Java XML Framework
- cocoon-block-axis :  Java XML Framework
- cocoon-block-batik :  Java XML Framework
- cocoon-block-bsf :  Java XML Framework
- cocoon-block-chaperon :  Java XML Framework
- cocoon-block-cron :  Java XML Framework
- cocoon-block-databases :  Java XML Framework
- cocoon-block-deli :  Java XML Framework
- cocoon-block-eventcache :  Java XML Framework
- cocoon-block-fop :  Java XML Framework
- cocoon-block-forms :  Java XML Framework
- cocoon-block-hsqldb :  Java XML Framework
- cocoon-block-html :  Java XML Framework
- cocoon-block-itext :  Java XML Framework
- cocoon-block-javaflow :  Java XML Framework
- cocoon-block-jfor :  Java XML Framework
- cocoon-block-jms :  Java XML Framework
- cocoon-block-jsp :  Java XML Framework
- cocoon-block-linkrewriter :  Java XML Framework
- cocoon-block-linotype :  Java XML Framework
- cocoon-block-lucene :  Java XML Framework
- cocoon-block-mail :  Java XML Framework
- cocoon-block-midi :  Java XML Framework
- cocoon-block-naming :  Java XML Framework
- cocoon-block-ojb :  Java XML Framework
- cocoon-block-paranoid :  Java XML Framework
- cocoon-block-petstore :  Java XML Framework
- cocoon-block-php :  Java XML Framework
- cocoon-block-poi :  Java XML Framework
- cocoon-block-portal :  Java XML Framework
- cocoon-block-portal-fw :  Java XML Framework
- cocoon-block-profiler :  Java XML Framework
- cocoon-block-proxy :  Java XML Framework
- cocoon-block-python :  Java XML Framework
- cocoon-block-qdox :  Java XML Framework
- cocoon-block-repository :  Java XML Framework
- cocoon-block-serializers :  Java XML Framework
- cocoon-block-session-fw :  Java XML Framework
- cocoon-block-slide :  Java XML Framework
- cocoon-block-slop :  Java XML Framework
- cocoon-block-stx :  Java XML Framework
- cocoon-block-taglib :  Java XML Framework
- cocoon-block-tour :  Java XML Framework
- cocoon-block-velocity :  Java XML Framework
- cocoon-block-web3 :  Java XML Framework
- cocoon-block-webdav :  Java XML Framework
- cocoon-block-woody :  Java XML Framework
- cocoon-block-xmldb :  Java XML Framework
- cocoon-block-xsp :  Java XML Framework
- cocoon-lenya :  Content Management System
- commons-jelly-tags-ojb :  A variety of tags for working with the ObjectBridge 
persiste...
- db-ojb :  ObjectRelationalBridge
- db-torque :  Persistence Layer
- jakarta-jetspeed :  Enterprise Information Portal
- jakarta-turbine-2 :  A servlet based framework.
- jakarta-turbine-3 :  A servlet based framework.
- jakarta-turbine-flux :  Servlet based framework
- jakarta-turbine-fulcrum :  Services Framework
- jakarta-turbine-jcs :  Cache
- jakarta-turbine-jyve :  FAQ-O-Matic
- jakarta-turbine-orgami :  Your organizer friend
- jakarta-turbine-site :  Servlet based framework
- scarab :  Issue Tracking Built for the Ages
- test-ojb :  ObjectRelationalBridge
- ws-xmlrpc :  A Java implementation of XML-RPC
- xml-forrest :  Forrest is an XML standards-oriented project documentation f...
- xml-xindice :  native XML database


Full details are available at:


http://brutus.apache.org:8080/gump/jakarta-commons-codec-11/commons-codec-11/index.html

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole jar [commons-codec-20040606.jar] identifier set to project name
 -INFO- Enable debug output, due to a sequence of 6 previous errors.
 -INFO- Failed with reason build failed


The following work was performed:
http://brutus.apache.org:8080/gump/jakarta-commons-codec-11/commons-codec-11/gump_work/build_jakarta-commons-codec-11_commons-codec-11.html
Work Name: build_jakarta-commons-codec-11_commons-codec-11 (Type: Build)
State: Failed
Elapsed: 0 hours, 0 minutes, 0 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -debug 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dcomponent.version=20040606 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-codec-11/codec]
CLASSPATH 

[GUMP@brutus]: jakarta-commons/commons-codec prerequisite failed

[Tim OBrien]

To whom it may satisfy...

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

Project commons-codec *no longer* has an issue.
Project State : 'Prerequisite Failed', Reason 'Build Failed'

Full details are available at:

http://brutus.apache.org:8080/gump/jakarta-commons/commons-codec/index.html

That said, some snippets follow:


The following annotations were provided:
 -INFO- Sole jar [commons-codec-20040524.jar] identifier set to project name
 -INFO- Prerequisite failed with reason build failed



To subscribe to this information via syndicated feeds:
 RSS: http://brutus.apache.org:8080/gump/jakarta-commons/commons-codec/rss.xml
 Atom: http://brutus.apache.org:8080/gump/jakarta-commons/commons-codec/atom.xml


--
Produced by Gump 2.0.3-alpha-0002.
[Run (20040524 15:00:12, brutus:brutus-public:20040524 15:00:12)]
http://brutus.apache.org:8080/gump/index.html
http://brutus.apache.org:8080/gump/options.html

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

[GUMP@lsd]: jakarta-commons/commons-codec failed

[Tim OBrien]

To whom it may engage...

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

Project commons-codec has an issue affecting it's community integration. This issue 
affects 129 projects. The current state is 'Failed', for reason 'Build Timed Out'

Full details are available at: 
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-codec.html, however some 
snippets follow:

-  -  -  -  - -- --  G U M P

Gump provided these annotations:

 - Info - Sole jar [/data3/gump/jakarta-commons/codec/dist/commons-codec-20040302.jar] 
identifier set to project name
 - Error - Failed with reason build timed out


-  -  -  -  - -- --  G U M P
Gump performed this work:

Work Name: build_jakarta-commons_commons-codec (Type: Build)
State: Failed
Elapsed: 0 hours, 60 minutes, 0 seconds
Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=true 
-Xbootclasspath/p:/data3/gump/xml-xerces2/java/build/xercesImpl.jar:/data3/gump/xml-xerces2/java/build/xmlParserAPIs.jar
 org.apache.tools.ant.Main -Dgump.merge=/data3/gump/gump-install/work/merge.xml 
-Dbuild.sysclasspath=only -Dcomponent.version=20040302 dist 
[Working Directory: /data3/gump/jakarta-commons/codec]
-
Buildfile: build.xml
 [property] dropping /data3/gump/jakarta-commons/codec/target/classes from path as it 
doesn't exist
 [property] dropping /data3/gump/jakarta-commons/codec/target/test-classes from path 
as it doesn't exist

init:
 [echo]  commons-codec 20040302 

prepare:
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/target
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/target/classes
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/target/conf
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/target/tests
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/target/test-reports

static:
 [copy] Copying 1 file to /data3/gump/jakarta-commons/codec/target/conf

compile:
[javac] Compiling 19 source files to 
/data3/gump/jakarta-commons/codec/target/classes
 [copy] Copying 6 files to /data3/gump/jakarta-commons/codec/target/classes

javadoc:
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/dist
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/dist/docs
[mkdir] Created dir: /data3/gump/jakarta-commons/codec/dist/docs/api
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.commons.codec...
  [javadoc] Loading source files for package org.apache.commons.codec.binary...
  [javadoc] Loading source files for package org.apache.commons.codec.digest...
  [javadoc] Loading source files for package org.apache.commons.codec.language...
  [javadoc] Loading source files for package org.apache.commons.codec.net...
  [javadoc] Constructing Javadoc information...
-




To subscribe to this information via syndicated feeds:
RSS: http://lsd.student.utwente.nl/gump/jakarta-commons/commons-codec.rss | Atom: 
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-codec.atom

--
Gump http://gump.apache.org/
[lsd]

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

RE: [HiveMind] Roll call, please!

[Tim OBrien]

What about moving HiveMind out of the Jakarta Commons?  I know this is a
controversial suggestion, but here me out a little. 

I think HiveMind is a great tool, and the project would benefit from having
a community that is focused on HiveMind.  Writing sub-modules to create
reusable HiveMind modules, extending HiveMind, etc, etc, etc...  

There are a number of projects in Jakarta Commons that might benefit from
finding an independent identity apart from Jakarta Commons - like Jelly,
maybe Math. (I like Jelly too, I'm not trying to start any fights.)

Jakarta Commons doesn't have room for another great project - for one, the
resources don't scale very well as there is one mailing list, one website
and 68 committers.  Sure, you can put up a mail filter and only read email
prefaced with [hivemind], but that's not what mailing lists were made for.

I like HiveMind so much, I don't want it to be in the Jakarta Commons.

This conversation might be more appropriate for [EMAIL PROTECTED],
but I refuse to crosspost. :-)  

Tim

-Original Message-
From: Howard M. Lewis Ship [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 12, 2003 5:03 PM
To: Jakarta Commons Developers List; 'David Solis'; Harish Krishnaswamy;
Essl Christian; Johan Lindquist; Andy Barnett; Bill Lear
Subject: [HiveMind] Roll call, please!

As I've posted on the the blog, I'm gearing up to form an initial HiveMind
community.

If you are interested in joining, please drop me an e-mail.

Once we form up, we should be able to get everyone commit rights to the
hivemind CVS repository.

Responsibilities will probably be pretty light; voting on a trickle of
issues. Most votes concern
addining additional team members, or votes about releases. The fun is not
the voting, but the
discussing of features and design issues.

Step two is to move HiveMind to Jakarta commons proper and set up dedicated
mailing lists. I'm
researching exactly what the rules and procedures for this are.

I feel the base framework is pretty much ready to head towards a 1.0
release; initial work will be
documentation and (even better) unit tests, plus creating additional modules
as outlined on my blog.
Of course, the whole point is we discuss, as a group, what should get done!

If you haven't worked on an open source project before ... come on in! The
water's fine! All it
takes is a desire to do some work, some skill at programming, and the right
attitude. It's very
rewarding.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com


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

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

RE: [VOTE] Promote commons-sandbox-daemon to Commons Proper

[Tim OBrien]

+0, I have not used it, but support the promotion.

Tim

-Original Message-
From: Stephen Colebourne [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, September 02, 2003 3:07 PM
To: Jakarta Commons Developers List
Subject: Re: [VOTE] Promote commons-sandbox-daemon to Commons Proper

+1
(though I have not used it, 'used by Tomcat' and 'no bugs filed' sounds
valid to me)

- Original Message -
From: Shapira, Yoav [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 02, 2003 3:09 PM
Subject: [VOTE] Promote commons-sandbox-daemon to Commons Proper



Howdy,
The tomcat team would like to promote commons-daemon to the
commons-proper and issue a 1.0 release to serve as a dependency for
tomcat 5.0 stable.

We have been using commons-daemon for a while, and there are no open
bugs filed against it.  We'll go through with the proper release
process, plan, and vote, as always, of course.  In fact, I'll probably
be the release manager for it.

Please vote on this promotion ;)  Thanks,

Yoav Shapira

---
Vote:  Promote commons-attributes to commons proper
[ X ] +1 I am in favor of the move, and will help support it
[ ] +0 I am in favor of the move, but am unable to help support it
[ ] -0 I am not in favor of the move
[ ] -1 I am against this proposal (must include a reason).
---




This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


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



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

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

RE: [codec] To do for 1.1.1

[Tim OBrien]

 -Original Message-
 From: Gary Gregory [mailto:[EMAIL PROTECTED] 

 Now I am thinking that 
 the build.xml could generate an overview.html based on 
 project.xml before invoking Javadoc. Is this too fancy? Is 
 duplication just better in this case?

I'd avoid modifying build.xml - this project gets built using Maven, and
while were at it, we should generate build.xml via the Maven ant goal.  (
Last time I tried this Gump did not like the build.xml file that Maven spit
out, and when Gump breaks, I usually sigh, throw my hands in the air, and
admit defeat. )

An overview.html based on project.xml - what do you mean?  Do you mean an
overview.html based on index.xml?  Opt for a separate approach, we need a
how to use this nonsense Javadoc the likes of Digester.

Tim



 
 Gary
 
 -Original Message-
 From: Tim OBrien [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 11, 2003 11:49
 To: 'Jakarta Commons Developers List'
 Cc: '[EMAIL PROTECTED]'
 Subject: RE: [codec] To do for 1.1.1
 
 CC'ing Oleg K.  Any issues with changing the capitalization 
 on URLCodec methods, per Gary's suggestion?
 
 Tim
 
  -Original Message-
  From: Gary Gregory [mailto:[EMAIL PROTECTED]
  Sent: Monday, August 11, 2003 1:39 PM
  To: 'Jakarta Commons Developers List'
  Subject: RE: [codec] To do for 1.1.1
  
  
  Here is another codec issue.
  
  In URLCodec there are too oddly named methods: urldecode()
  and urlencode(). The word-style caps are missing. I suggest 
  these be renamed to decodeUrl() and encodeUrl().
  
  Thoughts?
  
  Gary
  
  -Original Message-
  From: Tim O'Brien [mailto:[EMAIL PROTECTED]
  Sent: Monday, August 11, 2003 10:18
  To: Jakarta Commons Developers List
  Subject: Re: [codec] To do for 1.1.1
  
  I've done the release work in the past, be happy to do it
  again.  Or, if 
  you would like, I'd be glad to have another partner in crime.
  
  When B. Walstrum submitted the code for DoubleMetaphone, I
  assigned an 
  issue to him for a unit test.  I haven't seen any action as 
  of yet from 
  him.
  
  I'd say in addition to a unit test for DoubleMetaphone, we're
  lacking good 
  documentation (compared to Digester).
  
  Tim
  
  On Mon, 11 Aug 2003, Gary Gregory wrote:
  
   Hello Codec,
   
   So, is the only to-do for a codec 1.1.1 a DoubleMetaphone 
 unit test?
   
   Who knows enough to write one and has the time to do so?
   
   Who does the release work for this component?
   
   Gary
   
  
  --
  --
  Tim O'Brien
  Evanston, IL
  (847) 863-7045
  [EMAIL PROTECTED]
  
  
  
  
 -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

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

RE: [docs] Crappy build system

[Tim OBrien]

 -Original Message-
 From: Robert Leland [mailto:[EMAIL PROTECTED] 
 
 Henri Yandell wrote:
 
 Jakarta Commons build system for the website is very very crappy. 
 Regardless of whether things move to Maven or some other 
 look and feel, I'd like to check in the jars needed so that 
 people don't have to go 
 around hunting in jakarta-velocity, jakarta-site2 and who 
 knows where 
 else.
 

Henri, +1.  I brought this up before and was told that checking JAR files
into CVS was verboten.  If you are familiar with the process of building the
commons site, you'll recognize this as hot air - we're depending on JARs
checked into the CVS modules of other projects.

 Contributions are always welcome, then maybe the Commons build 
 system for the web
 site will go from being very very  crappy, to just crappy. 
 ;-) ! Could you elaborate on this ? When you say jars what 
 are you referring to ?
 

He's referring to the fact that one customizes a build.properties which
refers to jar files checked into the velocity project.  Or, (and this was
added only recently), you can point to the same jars which are checked into
the jakarta-site2 module.

 
 Is anyone against this? Is there some reason for the current 
 confusing setup?
 

As a half measure, please check the required JARs into CVS.  From there we
should consider Maven or simply having the build.xml retrieve the JARs from
a URL.

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

RE: [codec] To do for 1.1.1

[Tim OBrien]

CC'ing Oleg K.  Any issues with changing the capitalization on URLCodec
methods, per Gary's suggestion?

Tim

 -Original Message-
 From: Gary Gregory [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 11, 2003 1:39 PM
 To: 'Jakarta Commons Developers List'
 Subject: RE: [codec] To do for 1.1.1
 
 
 Here is another codec issue.
 
 In URLCodec there are too oddly named methods: urldecode() 
 and urlencode(). The word-style caps are missing. I suggest 
 these be renamed to decodeUrl() and encodeUrl().
 
 Thoughts?
 
 Gary
 
 -Original Message-
 From: Tim O'Brien [mailto:[EMAIL PROTECTED] 
 Sent: Monday, August 11, 2003 10:18
 To: Jakarta Commons Developers List
 Subject: Re: [codec] To do for 1.1.1
 
 I've done the release work in the past, be happy to do it 
 again.  Or, if 
 you would like, I'd be glad to have another partner in crime.
 
 When B. Walstrum submitted the code for DoubleMetaphone, I 
 assigned an 
 issue to him for a unit test.  I haven't seen any action as 
 of yet from 
 him.
 
 I'd say in addition to a unit test for DoubleMetaphone, we're 
 lacking good 
 documentation (compared to Digester).
 
 Tim
 
 On Mon, 11 Aug 2003, Gary Gregory wrote:
 
  Hello Codec,
  
  So, is the only to-do for a codec 1.1.1 a DoubleMetaphone unit test?
  
  Who knows enough to write one and has the time to do so?
  
  Who does the release work for this component?
  
  Gary
  
 
 -- 
 --
 Tim O'Brien
 Evanston, IL
 (847) 863-7045
 [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

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

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-21/commons-codec.html


Buildfile: build.xml

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/lib

get-deps:

compile:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] Compiling 15 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/classes

compile-tests:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/test-classes
[javac] Compiling 9 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/test-classes
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:67:
 package junit.framework does not exist
[javac] import junit.framework.Test;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:68:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:69:
 package junit.framework does not exist
[javac] import junit.framework.TestSuite;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:76:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.base64.Base64Test
[javac] public class Base64Test extends TestCase {
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:98:
 cannot resolve symbol
[javac] symbol  : class Test 
[javac] location: class org.apache.commons.codec.base64.Base64Test
[javac] public static Test suite() {
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java:67:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java:76:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.binary.Base64Test
[javac] public class Base64Test extends TestCase {
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/HexTest.java:66:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/HexTest.java:74:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.binary.HexTest
[javac] public class HexTest extends TestCase {
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:63:
 package junit.framework does not exist
[javac] import junit.framework.Test;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:64:
 package junit.framework does not exist
[javac] import junit.framework.TestSuite;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:66:
 cannot resolve symbol
[javac] symbol  : class StringEncoder 
[javac] location: package codec
[javac] import org.apache.commons.codec.StringEncoder;
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java:63:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java:70:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.StringEncoderAbstractTest
[javac] public abstract class StringEncoderAbstractTest extends TestCase {
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:79:
 cannot resolve symbol
[javac] symbol  : class Test 
[javac] location: class 

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-20/commons-codec.html


Buildfile: build.xml

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/lib

get-deps:

compile:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] Compiling 15 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/classes

compile-tests:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/test-classes
[javac] Compiling 9 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/test-classes
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:67:
 package junit.framework does not exist
[javac] import junit.framework.Test;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:68:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:69:
 package junit.framework does not exist
[javac] import junit.framework.TestSuite;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:76:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.base64.Base64Test
[javac] public class Base64Test extends TestCase {
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/base64/Base64Test.java:98:
 cannot resolve symbol
[javac] symbol  : class Test 
[javac] location: class org.apache.commons.codec.base64.Base64Test
[javac] public static Test suite() {
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java:67:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/Base64Test.java:76:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.binary.Base64Test
[javac] public class Base64Test extends TestCase {
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/HexTest.java:66:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/binary/HexTest.java:74:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.binary.HexTest
[javac] public class HexTest extends TestCase {
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:63:
 package junit.framework does not exist
[javac] import junit.framework.Test;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:64:
 package junit.framework does not exist
[javac] import junit.framework.TestSuite;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:66:
 cannot resolve symbol
[javac] symbol  : class StringEncoder 
[javac] location: package codec
[javac] import org.apache.commons.codec.StringEncoder;
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java:63:
 package junit.framework does not exist
[javac] import junit.framework.TestCase;
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/StringEncoderAbstractTest.java:70:
 cannot resolve symbol
[javac] symbol  : class TestCase 
[javac] location: class org.apache.commons.codec.StringEncoderAbstractTest
[javac] public abstract class StringEncoderAbstractTest extends TestCase {
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/test/org/apache/commons/codec/language/RefinedSoundexTest.java:79:
 cannot resolve symbol
[javac] symbol  : class Test 
[javac] location: class 

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-18/commons-codec.html


Buildfile: build.xml

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/lib

get-deps:

compile:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] Compiling 15 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 unclosed character literal
[javac] case '??':
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 illegal character: \65533
[javac] case '??':
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 unclosed character literal
[javac] case '??':
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:133:
 : expected
[javac] result.append('S');
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 unclosed character literal
[javac] case '??':
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 illegal character: \65533
[javac] case '??':
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 unclosed character literal
[javac] case '??':
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:171:
 : expected
[javac] result.append('N');
[javac]   ^
[javac] 8 errors

BUILD FAILED
/home/rubys/jakarta/jakarta-commons/codec/build.xml:36: Compile failed; see the 
compiler error output for details.

Total time: 2 seconds

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

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-17/commons-codec.html


Buildfile: build.xml

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/lib

get-deps:

compile:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] Compiling 15 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 unclosed character literal
[javac] case '??':
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 illegal character: \65533
[javac] case '??':
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 unclosed character literal
[javac] case '??':
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:133:
 : expected
[javac] result.append('S');
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 unclosed character literal
[javac] case '??':
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 illegal character: \65533
[javac] case '??':
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 unclosed character literal
[javac] case '??':
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:171:
 : expected
[javac] result.append('N');
[javac]   ^
[javac] 8 errors

BUILD FAILED
/home/rubys/jakarta/jakarta-commons/codec/build.xml:36: Compile failed; see the 
compiler error output for details.

Total time: 2 seconds

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

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-06-12/commons-codec.html


Buildfile: build.xml

init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/lib

get-deps:

compile:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] Compiling 15 source files to 
/home/rubys/jakarta/jakarta-commons/codec/target/classes
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 unclosed character literal
[javac] case '??':
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 illegal character: \65533
[javac] case '??':
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:132:
 unclosed character literal
[javac] case '??':
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:133:
 : expected
[javac] result.append('S');
[javac]   ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 unclosed character literal
[javac] case '??':
[javac]  ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 illegal character: \65533
[javac] case '??':
[javac]^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:170:
 unclosed character literal
[javac] case '??':
[javac] ^
[javac] 
/home/rubys/jakarta/jakarta-commons/codec/src/java/org/apache/commons/codec/language/DoubleMetaphone.java:171:
 : expected
[javac] result.append('N');
[javac]   ^
[javac] 8 errors

BUILD FAILED
/home/rubys/jakarta/jakarta-commons/codec/build.xml:36: Compile failed; see the 
compiler error output for details.

Total time: 2 seconds

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