[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: [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
> 
> > and would like to get involved in
> > this project.
> 
> 
> 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] 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:
> > > 
> > > > 2. Decouple Execution Context from the SCXML Model
> > > >
> > 
> >
> > > 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?
> >
> 
> 
> 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.
> 
> I 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.
> 

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.
> >
> 
> 
> I understand those constraints.
> 
> 
> > Becuase of this, I think that the public interface of scxml needs extra 
> > scrutiny before a
> release
> 
> 
> 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).
> >
> 
> 
> 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:

> > > 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.
> > >
> 
> 
> 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).
> >
> 
> 
> 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: [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:

> On 1/14/06, Tim OBrien <[EMAIL PROTECTED]> wrote:
> 

> 
> 
> 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:
> 
> Used primarily for testing, debugging and visual verification.
> 
> 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:
> 
>
> 
>
> 
>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] 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:
> 
> > 2. Decouple Execution Context from the SCXML Model
> >

 
> 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] 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.
> >
> 
> 
> 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.



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: [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=11352205513&r=1&w=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]

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  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]

[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: [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]

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]

[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  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: [vote] access for Niklas Gustavsson to the sandbox

[Tim OBrien]

+1

--- Brett Porter <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> I know the sandbox is meant to be open to any
> committers on request, but
> Niklas is a recent addition to an incubator project,
> so I thought it is
> best to double check with a vote.
> 
> Niklas contributed the original Ant refactoring to
> start commons-exec,
> and has some outstanding patches that I haven't had
> time to review and
> apply yet. I suspect I'm getting in his way right
> now.
> 
> I'd like to grant him access to commit to the
> sandbox so he can improve
> and document exec. I think at this point this is
> essential to give it
> some momentum. Plenty of people are interested, but
> they need to be able
> to use it first :)
> 
> I can still do lazy review and discuss the design on
> the list.
> 
> +1 from me.
> 
> - Brett
> 
>
-
> 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] 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: 
http://brutus.apache.org/gump/public/jakarta-co

[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: 
http://brutus.apache.org/gump/public/jakarta-commons/commons-codec/r

[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@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: http://brutus.apache.org/gump/public/jakarta-commons/commons-code

[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-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]: 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]: 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 org/apache/commons/codec/net/Qu

[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: [math] Project Maturity?

[Tim OBrien]

>>Mark R. Diggory wrote:
>> 3.) Test Coverage.
>
>The coverage report doesn't seem to be available from the jakarta
>site. Can I have a look at it somewhere else?

I claim responsibility for this.  I had (long ago) removed the report from
commons-math because I the clover version was incompatible with the Maven
plugin.

This problem has been solved in the meantime.  I'll reintegrate Clover into
the site build and publish it later on today.

>- It has been already discussed but can't we load off DoubleArray
>  and related classes to [collections] or the new [pcollections]?

I would like to explore this possibility.

Tim

-
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]

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]

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]

> -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: [math] checkstyle.wrap.operator = ignore

[Tim OBrien]

Take a look at checkstyle.xml.  Since, I'm building with the latest Maven
SNAPSHOT, I'm using the XML configuration file for checkstyle, and I set
this to "eol".

Feel free to change this if another setting makes sense.  Code formatting
discussions are religious, and I'd rather just share a common standard.

Are we standardized on using the checkstyle.xml yet? 

Tim

-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 10, 2003 8:05 AM
To: Jakarta Commons Developers List
Subject: [math] checkstyle.wrap.operator = ignore


I'm concerned that this property does not actually do what we think it 
is doing. "ignore" is used because there were problems using the "eol" 
string in the flat property files. Anyways this forces the checkstyle 
parser to require all operators to be at the end of the lines vs 
beginning of lines. There is no way to ignore if its at the end or 
beginning of the line.

Most autoformaters (Eclipse in my case) format according the checkstyle 
spec such that all operators fall at the beginnings (I don't see a way 
to change this in Eclipse at least). I suspect it covers more IDE cases 
to have this set property removed so it defaults to the beginning of the 
line.

-Mark


-
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:



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 org.apache.commons.codec.l

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:



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 org.apache.commons.codec.l

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:



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 org.apache.commons.codec.l

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:



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 org.apache.commons.codec.l

[GUMP] Build Failure - commons-codec

[Tim OBrien]

This email is autogenerated from the output from:



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:



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:



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]