date:20041008

The following issue has been updated:

Updater: Michael Altenhofen (mailto:[EMAIL PROTECTED])
   Date: Fri, 8 Oct 2004 12:43 AM
Changes:
 Attachment changed to jelly-tags-soap-patch.txt
-
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/JELLY-154?page=history

-
View the issue:
  http://issues.apache.org/jira/browse/JELLY-154

Here is an overview of the issue:
-
Key: JELLY-154
Summary: invoke tag should allow to support literal parameters in nested tags
   Type: Improvement

 Status: Unassigned
   Priority: Major

Project: jelly
 Components: 
 taglib.soap

   Assignee: 
   Reporter: Michael Altenhofen

Created: Fri, 8 Oct 2004 12:42 AM
Updated: Fri, 8 Oct 2004 12:43 AM

Description:
The current version (1.6) of InvokeTag's doTag method does not allow me to write 
something like this:

?xml version=1.0?
j:jelly trim=false xmlns:soap=jelly:soap xmlns:j=jelly:core 
xmlns:ju=jelly:util
j:catch var=ex

   1. Define variables to hold invocation parameters
   j:set 
var=endpointhttp://aws-beta.amazon.com/onca/soap?Service=AWSProductData/j:set
   j:set var=namespace/
   j:set var=methodItemSearch/j:set
   2. Load the parameters for the call from the file itemssearch_params.xml  
   ju:loadText file=itemsearch_params.xml var=params/
   3. Invoke the web service using the parameters we've just read in
   soap:invoke endpoint=${endpoint} namespace=${namespace} 
method=${method}${params}/soap:invoke
/j:catch
j:if test=${ex != null}
   Execption ${ex.message} occured
/j:if

/j:jelly

I've posted this issue into standard bugzilla (Bug #31542) but was advised to post it 
here again.  


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

Re: [jelly] XMLOutput.data(Object)

2004-10-08 Thread Paul Libbrecht

Le 8 oct. 04, à 02:08, Dion Gillard a écrit :
On Thu, 7 Oct 2004 11:40:27 +0200, Paul Libbrecht 
[EMAIL PROTECTED] wrote:
More precisely, it's passing objects around.
I see no other mechanism for a tag to pass an object to a tag that
called it... (which is not always a parent tag).
In keeping with the XMLOutput class and it's API, how about naming it
write(Object) instead of data(Object) having a method called data just
doesn't seem right to me.
Ok with write(Object), I think this isn't so appropriate since all 
methods of XMLOutput do write something... I was imitating 
startElement() or characterData() (all coming from SAX).
Maybe best would be objectData().

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

[jira] Created: (JELLY-154) invoke tag should allow to support literal parameters in nested tags

Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://issues.apache.org/jira/browse/JELLY-154

Here is an overview of the issue:
-
Key: JELLY-154
Summary: invoke tag should allow to support literal parameters in nested tags 
   Type: Improvement

 Status: Unassigned
   Priority: Major

Project: jelly
 Components: 
 taglib.soap

   Assignee: 
   Reporter: Michael Altenhofen

Created: Fri, 8 Oct 2004 12:42 AM
Updated: Fri, 8 Oct 2004 12:42 AM

Description:
The current version (1.6) of InvokeTag's doTag method does not allow me to write 
something like this:

?xml version=1.0?
j:jelly trim=false xmlns:soap=jelly:soap xmlns:j=jelly:core 
xmlns:ju=jelly:util
j:catch var=ex

   1. Define variables to hold invocation parameters
   j:set 
var=endpointhttp://aws-beta.amazon.com/onca/soap?Service=AWSProductData/j:set
   j:set var=namespace/
   j:set var=methodItemSearch/j:set
   2. Load the parameters for the call from the file itemssearch_params.xml  
   ju:loadText file=itemsearch_params.xml var=params/
   3. Invoke the web service using the parameters we've just read in
   soap:invoke endpoint=${endpoint} namespace=${namespace} 
method=${method}${params}/soap:invoke
/j:catch
j:if test=${ex != null}
   Execption ${ex.message} occured
/j:if

/j:jelly

I've posted this issue into standard bugzilla (Bug #31542) but was advised to post it 
here again.  


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (JELLY-155) body not correctly parsed

Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://issues.apache.org/jira/browse/JELLY-155

Here is an overview of the issue:
-
Key: JELLY-155
Summary: body not correctly parsed
   Type: Bug

 Status: Unassigned
   Priority: Major

Project: jelly
 Components: 
 taglib.xml

   Assignee: 
   Reporter: Michael Altenhofen

Created: Fri, 8 Oct 2004 12:50 AM
Updated: Fri, 8 Oct 2004 12:50 AM

Description:
In the current version (1.6) of ParseTagSupport the code of parseBody may generate an 
empty document, especially if the body is generated by a nested jelly tag.
Looks like there is nobody notifying the writer that new tags are found, so the writer 
simply ignores any data that is written out thus producing and empty document.

Replacing the method body with 

  return parseText(getBodyText(false));

seems to do the trick.

This issue has also been posted to the bugzilla tracking system (BUG # 31534), but I 
was advised to post it here again.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

[jira] Created: (JELLY-156) tags.xmlunit: body not correctly parsed

Message:

  A new issue has been created in JIRA.

-
View the issue:
  http://issues.apache.org/jira/browse/JELLY-156

Here is an overview of the issue:
-
Key: JELLY-156
Summary: tags.xmlunit: body not correctly parsed
   Type: Bug

 Status: Unassigned
   Priority: Major

Project: jelly

   Assignee: 
   Reporter: Michael Altenhofen

Created: Fri, 8 Oct 2004 12:57 AM
Updated: Fri, 8 Oct 2004 12:57 AM

Description:
Remark: I'm assigning this to Unknown component since I cannot select tags.xmlunit.

Similar to the probelm described for the xml tag lib, the xmlunit tag lib doesn't 
correctly parse bodies.

E.g., with the current version (1.6) of ParseTagSupport I can't do the following:

[...]
   xu:assertDocumentsEqual expected=result.xml
 xu:actual
   soap:invoke endpoint=${endpoint} namespace=${namespace} 
method=${method}${params}/soap:invoke
 /xu:actual
   /xu:assertDocumentsEqual   
[...]

The result produced by the soap invoke call will be transformed into an empty document.

Changing the method body of parseBody to

return parseText(getBodyText(false));

does the trick.

This issue has also been posted via bugzilla (BUG #31544), but I've been adviced to 
post it here again.


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

DO NOT REPLY [Bug 31572] - [LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31572.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31572

[LANG] - o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 08:12 ---
Congratulations! That is great!

I think a RC1 is better for projects than just a CVS version. Unfortunately, I
guess I cannot be much useful in jakarta-commons, since I am not committer.
Anyway, if you need help for the release, let me know!. I will be very glad to
help. :-D

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

[jira] Commented: (JELLY-154) invoke tag should allow to support literal parameters in nested tags

The following comment has been added to this issue:

 Author: Paul Libbrecht
Created: Fri, 8 Oct 2004 1:20 AM
   Body:
In your example, I don't understand why using params=${params} is not enough.
Maybe you can provide another example ?
Do you want to do something like:
   soap:invoke endpoint=${endpoint} namespace=${namespace} method=${method}
${paramSeries1}
${paramSeries2} 
/soap:invoke

Or maybe something more elaborate such as using j:forEach ?

thanks

paul
-
View this comment:
  http://issues.apache.org/jira/browse/JELLY-154?page=comments#action_53832

-
View the issue:
  http://issues.apache.org/jira/browse/JELLY-154

Here is an overview of the issue:
-
Key: JELLY-154
Summary: invoke tag should allow to support literal parameters in nested tags
   Type: Improvement

 Status: Unassigned
   Priority: Major

Project: jelly
 Components: 
 taglib.soap

   Assignee: 
   Reporter: Michael Altenhofen

Created: Fri, 8 Oct 2004 12:42 AM
Updated: Fri, 8 Oct 2004 1:20 AM

Description:
The current version (1.6) of InvokeTag's doTag method does not allow me to write 
something like this:

?xml version=1.0?
j:jelly trim=false xmlns:soap=jelly:soap xmlns:j=jelly:core 
xmlns:ju=jelly:util
j:catch var=ex

   1. Define variables to hold invocation parameters
   j:set 
var=endpointhttp://aws-beta.amazon.com/onca/soap?Service=AWSProductData/j:set
   j:set var=namespace/
   j:set var=methodItemSearch/j:set
   2. Load the parameters for the call from the file itemssearch_params.xml  
   ju:loadText file=itemsearch_params.xml var=params/
   3. Invoke the web service using the parameters we've just read in
   soap:invoke endpoint=${endpoint} namespace=${namespace} 
method=${method}${params}/soap:invoke
/j:catch
j:if test=${ex != null}
   Execption ${ex.message} occured
/j:if

/j:jelly

I've posted this issue into standard bugzilla (Bug #31542) but was advised to post it 
here again.  


-
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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

AW: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread Daniel Florey

Hi all,
I'll have a look at Digester again today and will compare the two approaches
finally for use in i18n.
As I know Oliver Zeigermann for a long time and he really is the master of
xml/sgml I everyone should give xmlio (good name indeed) a try.
Personally I like technologies that keep it very simple so that you
understand at the first sight what's going on without hiding too much
implicit logic.
As I stated earlier we have used Digester in a large project where a lot xml
parsing took place and we had some trouble with it (but that's some time
ago).
So I'd vote for putting the xmlio into the sandbox and let everybody have a
look at it. Even if it will never make it to commons components, it is worth
to have a look at its simplicity.
Regards,
Daniel


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im
Auftrag von Martin Cooper
Gesendet: Donnerstag, 7. Oktober 2004 23:46
An: Jakarta Commons Developers List
Betreff: Re: XML Im-/Ex-porter into Commons Sandbox

On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
[EMAIL PROTECTED] wrote:
 One of the key items in the commons charter is allowing different
solutions
 to the same problem. So far, we have tended to avoid this (for example, I
 took a conflicting primitives design elsewhere) however we should not
block
 this.
 
 What is being requested at this point is to factor out some code from
 another project (Slide) to commons. This is IMHO perfectly good and what
 commons is for. The code is going to the sandbox where we can all
determine
 whether it is a good addition to the commons-proper fold. (eg. performance
 tests, code design, documentation). Who knows maybe the ideas will end up
as
 digester 2! IMO thats what the sandbox is for.

In general, I agree with you. However, in this case, the reason for
bringing this component to the sandbox is because another component
that has only just arrived in the sandbox (i18n) wants to use it
instead of Digester. It seems that this XML component wasn't going to
be brought to Commons (at least for the moment) until there was
mention that i18n wanted to use it.

I'm not sure that I like the idea of new sandbox components bringing
along other components as baggage when there is already suitable
functionality available in Commons Proper. On the other hand, I would
not be opposed to bringing the XML component in _later_, and letting
it stand or fall on its own.

--
Martin Cooper


 
 BTW, I don't disagree with the comments about bad dependency management
 below, I just disagree that that necessarily implies only ever supporting
 digester.
 
 Finally, the name ;-)
 xmlio  (ie. xml io)
 sax
 saxio
 
 Typically, the commons project is named after the technology it works on.
 Without having seen the code its also difficult to judge what a good name
 would be ;-) I quite like xmlio myself.
 
 Stephen
 
 
 
 - Original Message -
 From: David Graham [EMAIL PROTECTED]
  This will create bloat problems for clients that use Digester.  For
  example:  Struts uses Digester for xml parsing.  In the future Struts
may
  want to use the new i18n component.  However, if i18n uses XML
Im-Exporter
  then Struts must drag that along too despite already having a perfectly
  fine xml parser in its dependency list.
 
  Struts is just one example.  It will be even worse for inter-commons
  project dependencies.
 
  Bad dependency management has plagued commons components and it's just
  recently started to get better.  If all commons components use Digester
  then we can avoid having to duplicate functionality and bloat
  dependencies.
 
  I don't understand what's wrong with Digester that necessitates a new
  parsing library.  I've been able to write complex parsing rules in a
  matter of minutes.
 
  David
 
  --- Oliver Zeigermann [EMAIL PROTECTED] wrote:
 
   Folks,
  
   on the request of Daniel Florey I'd like to create at least one new
   sandbox component for a tool that allows easy import / export of XML
   into / from Java. It is used by Jakarta Slide and in the components
   Daniel introduced.
  
   I know this is a bit delicate as there already is Digester around in
   commons. However, the audience for my tool is different from
   Digester's. XML Im-/Exporter is geared towards high performance use
   for people who are very familiar with XML. It is just a little bit
   more than pure SAX. It also has a different philosohie than Digester.
  
   Having said that I hope not to cause any inconvenience with this...
  
   Preparing this now  and cheers,
 
 -
 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]

DO NOT REPLY [Bug 31597] New: - Incorrect test for availability of log4j

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31597.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31597

Incorrect test for availability of log4j

   Summary: Incorrect test for availability of log4j
   Product: Commons
   Version: 1.0.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Logging
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Corrrected code from LogFactoryImpl is below.  Log4j is only available if the
the class loader that loads Log4JLogger can load Logger.  The orginal test
is incorrect when both of these conditions are met
a.) the context loader can load Logger ( directly or not ), and
b.) Log4jLogger is actually loaded by a parent of the loader that loads Logger.

The failure of course occurs because Log4jLogger has a direct dep on Logger.

protected boolean isLog4JAvailable() {

try {
 
/* incorrect */
//loadClass(org.apache.log4j.Logger);
//loadClass(org.apache.commons.logging.impl.Log4JLogger);
/* /incorrect */
   
loadClass(org.apache.commons.logging.impl.Log4JLogger).getClassLoader().loadClass(
org.apache.log4j.Logger );
return (true);
} catch (Throwable t) {
return (false);
}
}

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

[digester] AW: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread Daniel Florey

The digester site seems to be broken. All links to the docs dont work

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im
Auftrag von Daniel Florey
Gesendet: Freitag, 8. Oktober 2004 09:32
An: 'Jakarta Commons Developers List'; 'Martin Cooper'
Betreff: AW: XML Im-/Ex-porter into Commons Sandbox

Hi all,
I'll have a look at Digester again today and will compare the two approaches
finally for use in i18n.
As I know Oliver Zeigermann for a long time and he really is the master of
xml/sgml I everyone should give xmlio (good name indeed) a try.
Personally I like technologies that keep it very simple so that you
understand at the first sight what's going on without hiding too much
implicit logic.
As I stated earlier we have used Digester in a large project where a lot xml
parsing took place and we had some trouble with it (but that's some time
ago).
So I'd vote for putting the xmlio into the sandbox and let everybody have a
look at it. Even if it will never make it to commons components, it is worth
to have a look at its simplicity.
Regards,
Daniel


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im
Auftrag von Martin Cooper
Gesendet: Donnerstag, 7. Oktober 2004 23:46
An: Jakarta Commons Developers List
Betreff: Re: XML Im-/Ex-porter into Commons Sandbox

On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
[EMAIL PROTECTED] wrote:
 One of the key items in the commons charter is allowing different
solutions
 to the same problem. So far, we have tended to avoid this (for example, I
 took a conflicting primitives design elsewhere) however we should not
block
 this.
 
 What is being requested at this point is to factor out some code from
 another project (Slide) to commons. This is IMHO perfectly good and what
 commons is for. The code is going to the sandbox where we can all
determine
 whether it is a good addition to the commons-proper fold. (eg. performance
 tests, code design, documentation). Who knows maybe the ideas will end up
as
 digester 2! IMO thats what the sandbox is for.

In general, I agree with you. However, in this case, the reason for
bringing this component to the sandbox is because another component
that has only just arrived in the sandbox (i18n) wants to use it
instead of Digester. It seems that this XML component wasn't going to
be brought to Commons (at least for the moment) until there was
mention that i18n wanted to use it.

I'm not sure that I like the idea of new sandbox components bringing
along other components as baggage when there is already suitable
functionality available in Commons Proper. On the other hand, I would
not be opposed to bringing the XML component in _later_, and letting
it stand or fall on its own.

--
Martin Cooper


 
 BTW, I don't disagree with the comments about bad dependency management
 below, I just disagree that that necessarily implies only ever supporting
 digester.
 
 Finally, the name ;-)
 xmlio  (ie. xml io)
 sax
 saxio
 
 Typically, the commons project is named after the technology it works on.
 Without having seen the code its also difficult to judge what a good name
 would be ;-) I quite like xmlio myself.
 
 Stephen
 
 
 
 - Original Message -
 From: David Graham [EMAIL PROTECTED]
  This will create bloat problems for clients that use Digester.  For
  example:  Struts uses Digester for xml parsing.  In the future Struts
may
  want to use the new i18n component.  However, if i18n uses XML
Im-Exporter
  then Struts must drag that along too despite already having a perfectly
  fine xml parser in its dependency list.
 
  Struts is just one example.  It will be even worse for inter-commons
  project dependencies.
 
  Bad dependency management has plagued commons components and it's just
  recently started to get better.  If all commons components use Digester
  then we can avoid having to duplicate functionality and bloat
  dependencies.
 
  I don't understand what's wrong with Digester that necessitates a new
  parsing library.  I've been able to write complex parsing rules in a
  matter of minutes.
 
  David
 
  --- Oliver Zeigermann [EMAIL PROTECTED] wrote:
 
   Folks,
  
   on the request of Daniel Florey I'd like to create at least one new
   sandbox component for a tool that allows easy import / export of XML
   into / from Java. It is used by Jakarta Slide and in the components
   Daniel introduced.
  
   I know this is a bit delicate as there already is Digester around in
   commons. However, the audience for my tool is different from
   Digester's. XML Im-/Exporter is geared towards high performance use
   for people who are very familiar with XML. It is just a little bit
   more than pure SAX. It also has a different philosohie than Digester.
  
   Having said that I hope not to cause any inconvenience with this...
  
   Preparing this now  and cheers,
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/descriptor - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/descriptor - 
New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/example - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/example - New 
directory

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

cvs commit: jakarta-commons-sandbox/contract/xdocs/images - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/xdocs/images - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/context - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/context - New 
directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java/org/apache - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints - 
New directory

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

cvs commit: jakarta-commons-sandbox/contract/src - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/config - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/config - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/i18n - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/i18n - New 
directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract - New directory

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

cvs commit: jakarta-commons-sandbox/contract/xdocs - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/xdocs - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/util - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/util - New 
directory

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

cvs commit: jakarta-commons-sandbox/contract - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java/org - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/store - New directory

dflorey 2004/10/08 02:36:08

  jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/store - New 
directory

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

cvs commit: jakarta-commons-sandbox/contract/src/java/org/apache/commons - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/src/java/org/apache/commons - New directory

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

cvs commit: jakarta-commons-sandbox/contract/lib - New directory

dflorey 2004/10/08 02:36:07

  jakarta-commons-sandbox/contract/lib - New directory

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

cvs commit: jakarta-commons-sandbox/contract/xdocs/images contract-logo-white.png

dflorey 2004/10/08 02:36:21

  Added:   contract/xdocs index.xml downloads.xml navigation.xml
   contract/src/java/org/apache/commons/contract/constraints
NumberConstraints.java CastException.java
Constraints.java ArrayConstraints.java
MapConstraints.java ListConstraints.java
Castable.java DateConstraints.java
TreeConstraints.java ValidationException.java
BooleanConstraints.java LocaleConstraints.java
Unconstrained.java StringConstraints.java
Validatable.java
   contract project.properties NOTICE.txt project.xml build.xml
LICENSE.txt
   contract/src/java/org/apache/commons/contract/util
InteractiveMainWrapper.java MainWrapper.java
   contract/src/config constraints.xml example.xml util.xml
exceptions.xml
   contract/src/java/org/apache/commons/contract Result.java
Context.java Processor.java Executor.java
EnvironmentProvider.java Store.java
EnvironmentConsumer.java StoreException.java
ContractViolationException.java
   contract/src/java/org/apache/commons/contract/context
VMContext.java
   contract/src/java/org/apache/commons/contract/example
SimpleMain.java SpeedCalculator.java
   contract/src/java/org/apache/commons/contract/descriptor
Descriptor.java ResultDescriptor.java
RequiredEnvironmentDescriptor.java
ResultEntryDescriptor.java ParameterDescriptor.java
ProvidedEnvironmentDescriptor.java
StateDescriptor.java
   contract/src/java/org/apache/commons/contract/i18n
ParameterMessage.java
   contract/lib commons-i18n-0.2.jar
   contract/src/java/org/apache/commons/contract/store
Environment.java
   contract/xdocs/images contract-logo-white.png
  Log:
  Extracted contract based programming core from Slide Projector to commons sandbox
  
  Revision  ChangesPath
  1.1  jakarta-commons-sandbox/contract/xdocs/index.xml
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/xdocs/index.xml?rev=1.1
  
  
  1.1  jakarta-commons-sandbox/contract/xdocs/downloads.xml
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/xdocs/downloads.xml?rev=1.1
  
  
  1.1  jakarta-commons-sandbox/contract/xdocs/navigation.xml
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/xdocs/navigation.xml?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/NumberConstraints.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/NumberConstraints.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/CastException.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/CastException.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/Constraints.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/Constraints.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/ArrayConstraints.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/ArrayConstraints.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/MapConstraints.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/MapConstraints.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/ListConstraints.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/ListConstraints.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/Castable.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/contract/src/java/org/apache/commons/contract/constraints/Castable.java?rev=1.1
  
  
  1.1

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/option OptionImpl.java

roxspring2004/10/08 03:22:07

  Modified:cli/src/java/org/apache/commons/cli2/option OptionImpl.java
  Log:
  OptionImpl now avoids NullPointerExceptions
  
  Revision  ChangesPath
  1.5   +17 -6 
jakarta-commons/cli/src/java/org/apache/commons/cli2/option/OptionImpl.java
  
  Index: OptionImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/option/OptionImpl.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- OptionImpl.java   7 Sep 2004 00:18:23 -   1.4
  +++ OptionImpl.java   8 Oct 2004 10:22:07 -   1.5
  @@ -69,18 +69,29 @@
   final OptionImpl that = (OptionImpl)thatObj;
   
   return getId() == that.getId()
  - getPreferredName().equals(that.getPreferredName())
  - (getDescription() == that.getDescription()
  -|| getDescription().equals(that.getDescription()))
  - getPrefixes().equals(that.getPrefixes())
  - getTriggers().equals(that.getTriggers());
  +  equals(getPreferredName(),that.getPreferredName())
  +  equals(getDescription(),that.getDescription())
  +  equals(getPrefixes(),that.getPrefixes())
  +  equals(getTriggers(),that.getTriggers());
   }
   else {
   return false;
   }
   }
   
  -public int hashCode() {
  + private boolean equals(Object left, Object right) {
  + if(left==null  right==null){
  + return true;
  + }
  + else if(left==null || right==null){
  + return false;
  + }
  + else{
  + return left.equals(right);
  + }
  + }
  +
  + public int hashCode() {
   int hashCode = getId();
   hashCode = hashCode * 37 + getPreferredName().hashCode();
   if (getDescription() != null) {
  
  
  

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

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/option GroupImpl.java

roxspring2004/10/08 03:23:11

  Modified:cli/src/java/org/apache/commons/cli2/option GroupImpl.java
  Log:
  GroupImpl.validate() always validates instances of Group since they may contain 
other options that need validating
  
  Revision  ChangesPath
  1.6   +3 -0  
jakarta-commons/cli/src/java/org/apache/commons/cli2/option/GroupImpl.java
  
  Index: GroupImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/option/GroupImpl.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- GroupImpl.java2 Oct 2004 13:16:21 -   1.5
  +++ GroupImpl.java8 Oct 2004 10:23:11 -   1.6
  @@ -227,6 +227,9 @@
   if(option.isRequired()){
   option.validate(commandLine);
   }
  +if(option instanceof Group){
  + option.validate(commandLine);
  +}
   // if the child option is present then validate it
   if (commandLine.hasOption(option)) {
   if (++present  maximum) {
  
  
  

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

Re: XML Im-/Ex-porter into Commons Sandbox

xmlio sounds like a nice name. I will prepare something to check in
for general inspection...

Oliver


On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
[EMAIL PROTECTED] wrote:
 One of the key items in the commons charter is allowing different solutions
 to the same problem. So far, we have tended to avoid this (for example, I
 took a conflicting primitives design elsewhere) however we should not block
 this.
 
 What is being requested at this point is to factor out some code from
 another project (Slide) to commons. This is IMHO perfectly good and what
 commons is for. The code is going to the sandbox where we can all determine
 whether it is a good addition to the commons-proper fold. (eg. performance
 tests, code design, documentation). Who knows maybe the ideas will end up as
 digester 2! IMO thats what the sandbox is for.
 
 BTW, I don't disagree with the comments about bad dependency management
 below, I just disagree that that necessarily implies only ever supporting
 digester.
 
 Finally, the name ;-)
 xmlio  (ie. xml io)
 sax
 saxio
 
 Typically, the commons project is named after the technology it works on.
 Without having seen the code its also difficult to judge what a good name
 would be ;-) I quite like xmlio myself.
 
 Stephen
 
 
 
 - Original Message -
 From: David Graham [EMAIL PROTECTED]
  This will create bloat problems for clients that use Digester.  For
  example:  Struts uses Digester for xml parsing.  In the future Struts may
  want to use the new i18n component.  However, if i18n uses XML Im-Exporter
  then Struts must drag that along too despite already having a perfectly
  fine xml parser in its dependency list.
 
  Struts is just one example.  It will be even worse for inter-commons
  project dependencies.
 
  Bad dependency management has plagued commons components and it's just
  recently started to get better.  If all commons components use Digester
  then we can avoid having to duplicate functionality and bloat
  dependencies.
 
  I don't understand what's wrong with Digester that necessitates a new
  parsing library.  I've been able to write complex parsing rules in a
  matter of minutes.
 
  David
 
  --- Oliver Zeigermann [EMAIL PROTECTED] wrote:
 
   Folks,
  
   on the request of Daniel Florey I'd like to create at least one new
   sandbox component for a tool that allows easy import / export of XML
   into / from Java. It is used by Jakarta Slide and in the components
   Daniel introduced.
  
   I know this is a bit delicate as there already is Digester around in
   commons. However, the audience for my tool is different from
   Digester's. XML Im-/Exporter is geared towards high performance use
   for people who are very familiar with XML. It is just a little bit
   more than pure SAX. It also has a different philosohie than Digester.
  
   Having said that I hope not to cause any inconvenience with this...
  
   Preparing this now  and cheers,
 
 -
 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: AW: XML Im-/Ex-porter into Commons Sandbox

On Fri, 8 Oct 2004 10:31:44 +0200, Daniel Florey [EMAIL PROTECTED] wrote:
 As I know Oliver Zeigermann for a long time and he really is the master of
 xml/sgml I everyone should give xmlio (good name indeed) a try.

I am certainly far from being a master in anything, but thanks for the
flattery ;)

 Personally I like technologies that keep it very simple so that you
 understand at the first sight what's going on without hiding too much
 implicit logic.

That's what it was designed for. 

 As I stated earlier we have used Digester in a large project where a lot xml
 parsing took place and we had some trouble with it (but that's some time
 ago).
 So I'd vote for putting the xmlio into the sandbox and let everybody have a
 look at it. Even if it will never make it to commons components, it is worth
 to have a look at its simplicity.

Agreed. Let me put it there and if it turns out to be crap or
unusable, we can certainly abondon it.

Oliver

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

Re: XML Im-/Ex-porter into Commons Sandbox

Ah, now I understand your fears. Just another XML-Java mapper flying
around ih the user list: http://beck.sourceforge.net/. However,
xmlio is not a mapper to Java objects, you just receiver augmented SAX
call backs. Enough talk, I will prepare something now...

Oliver


On Fri, 8 Oct 2004 12:27:37 +0200, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
 xmlio sounds like a nice name. I will prepare something to check in
 for general inspection...
 
 Oliver
 
 
 
 
 On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
 [EMAIL PROTECTED] wrote:
  One of the key items in the commons charter is allowing different solutions
  to the same problem. So far, we have tended to avoid this (for example, I
  took a conflicting primitives design elsewhere) however we should not block
  this.
 
  What is being requested at this point is to factor out some code from
  another project (Slide) to commons. This is IMHO perfectly good and what
  commons is for. The code is going to the sandbox where we can all determine
  whether it is a good addition to the commons-proper fold. (eg. performance
  tests, code design, documentation). Who knows maybe the ideas will end up as
  digester 2! IMO thats what the sandbox is for.
 
  BTW, I don't disagree with the comments about bad dependency management
  below, I just disagree that that necessarily implies only ever supporting
  digester.
 
  Finally, the name ;-)
  xmlio  (ie. xml io)
  sax
  saxio
 
  Typically, the commons project is named after the technology it works on.
  Without having seen the code its also difficult to judge what a good name
  would be ;-) I quite like xmlio myself.
 
  Stephen
 
 
 
  - Original Message -
  From: David Graham [EMAIL PROTECTED]
   This will create bloat problems for clients that use Digester.  For
   example:  Struts uses Digester for xml parsing.  In the future Struts may
   want to use the new i18n component.  However, if i18n uses XML Im-Exporter
   then Struts must drag that along too despite already having a perfectly
   fine xml parser in its dependency list.
  
   Struts is just one example.  It will be even worse for inter-commons
   project dependencies.
  
   Bad dependency management has plagued commons components and it's just
   recently started to get better.  If all commons components use Digester
   then we can avoid having to duplicate functionality and bloat
   dependencies.
  
   I don't understand what's wrong with Digester that necessitates a new
   parsing library.  I've been able to write complex parsing rules in a
   matter of minutes.
  
   David
  
   --- Oliver Zeigermann [EMAIL PROTECTED] wrote:
  
Folks,
   
on the request of Daniel Florey I'd like to create at least one new
sandbox component for a tool that allows easy import / export of XML
into / from Java. It is used by Jakarta Slide and in the components
Daniel introduced.
   
I know this is a bit delicate as there already is Digester around in
commons. However, the audience for my tool is different from
Digester's. XML Im-/Exporter is geared towards high performance use
for people who are very familiar with XML. It is just a little bit
more than pure SAX. It also has a different philosohie than Digester.
   
Having said that I hope not to cause any inconvenience with this...
   
Preparing this now  and cheers,
 
  -
  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]

DO NOT REPLY [Bug 24306] - Fileupload fails for forms with a large number of inputs

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=24306.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=24306

Fileupload fails for forms with a large number of inputs





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 10:41 ---
I encountered this problem, too. 
My form contained about 15 form fields and 5 file upload fields.
My threshold was 1 MB and so I wasted about 20 MB.

Simple workaround: I subclassed DefaultFileItemFactory and added a 
property sizeThresholdFormField. In createItem I created a default FileItem 
if isFormField was false. For form fields I created a FileItem with a 
threshold of sizeThresholdFormField.
So the waste of memory was much lower for form fields. On the other hand: if a 
textarea contains a lot of text it could be stored in a file, which is a loss 
of performance.

Usage: 
DiskFileUpload fileUpload = new DiskFileUpload (new HDFileItemFactory(1*1024 
*1024, 1024, repository) );

This created a FileUpload with thresholds of 1 MB for files and 1 KB for form 
fields.
In the above sample I would need 5 MB + some KB instead of 20 MB.

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

DO NOT REPLY [Bug 24306] - Fileupload fails for forms with a large number of inputs

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=24306.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=24306

Fileupload fails for forms with a large number of inputs





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 10:42 ---
Created an attachment (id=12996)
FileItemFactory with different Thresholds for file items and form fields

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

cvs commit: jakarta-commons-sandbox/contract/src/examples - New directory

dflorey 2004/10/08 03:44:53

  jakarta-commons-sandbox/contract/src/examples - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/examples/org - New directory

dflorey 2004/10/08 03:44:53

  jakarta-commons-sandbox/contract/src/examples/org - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/examples/org/apache/commons - New directory

dflorey 2004/10/08 03:44:53

  jakarta-commons-sandbox/contract/src/examples/org/apache/commons - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/examples/org/apache - New directory

dflorey 2004/10/08 03:44:53

  jakarta-commons-sandbox/contract/src/examples/org/apache - New directory

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

cvs commit: jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example SpeedCalculator.java SimpleMain.java

dflorey 2004/10/08 03:44:57

  Added:   contract/src/examples/org/apache/commons/contract/example
SpeedCalculator.java SimpleMain.java
  Removed: contract/src/java/org/apache/commons/contract/example
SpeedCalculator.java SimpleMain.java
  Log:
  Moven examples from main jar to examples jar
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/SpeedCalculator.java
  
  Index: SpeedCalculator.java
  ===
  /*
   * 
   * 
   * 
   * Copyright 2004 The Apache Software Foundation
   * 
   * Licensed under the Apache License, Version 2.0 (the License); you may not
   * use this file except in compliance with the License. You may obtain a copy of
   * the License at
   * 
   * http://www.apache.org/licenses/LICENSE-2.0
   * 
   * Unless required by applicable law or agreed to in writing, software
   * distributed under the License is distributed on an AS IS BASIS, WITHOUT
   * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
   * License for the specific language governing permissions and limitations under
   * the License.
   *  
   */
  package org.apache.commons.contract.example;
  
  import java.util.Map;
  
  import org.apache.commons.contract.Context;
  import org.apache.commons.contract.Processor;
  import org.apache.commons.contract.Result;
  import org.apache.commons.contract.constraints.NumberConstraints;
  import org.apache.commons.contract.constraints.StringConstraints;
  import org.apache.commons.contract.descriptor.ParameterDescriptor;
  import org.apache.commons.contract.descriptor.ResultDescriptor;
  import org.apache.commons.contract.descriptor.ResultEntryDescriptor;
  import org.apache.commons.contract.descriptor.StateDescriptor;
  import org.apache.commons.contract.i18n.ParameterMessage;
  import org.apache.commons.i18n.LocalizedMessage;
  
  public class SpeedCalculator implements Processor {
  public final static String SPEED = speed;
  
  private final static String DISTANCE = distance;
  private final static String TIME = time;
  private final static String UNIT = unit;
  private final static String SECONDS = s;
  private final static String MINUTES = min;
  private final static String HOURS = h;
  
  ParameterDescriptor[] parameterDescriptors = new ParameterDescriptor[]{
  new ParameterDescriptor(DISTANCE, new 
ParameterMessage(computeSpeed/parameter/distance), 
  new NumberConstraints(
  new Integer(0), null, true)),
  new ParameterDescriptor(UNIT, new 
ParameterMessage(computeSpeed/parameter/unit), 
  new StringConstraints(
  new String[]{SECONDS, MINUTES, HOURS})),
  new ParameterDescriptor(TIME, new 
ParameterMessage(computeSpeed/parameter/time), 
  NumberConstraints.POSITIVE)};
  
  ResultDescriptor[] resultDescriptors = new ResultDescriptor[]{new 
ResultDescriptor(
  StateDescriptor.OK_DESCRIPTOR,
  new ResultEntryDescriptor[]{new ResultEntryDescriptor(SPEED,
  new LocalizedMessage(computeSpeed/result/speed),
  new NumberConstraints(new Float(0.1), new 
Integer(Integer.MAX_VALUE)))})};
  
  /**
   * Computes the speed in meter per second from the given distance and time.
   * The time can be given in seconds, minutes or hours, depending on the
   * content of timeUnit.
   */
  public Result process(Map parameters, Context context) {
  float distance = ((Number)parameters.get(DISTANCE)).floatValue();
  float time = ((Number)parameters.get(TIME)).floatValue();
  String timeUnit = (String)parameters.get(UNIT);
  float speed;
  if (timeUnit.equals(s)) speed = distance / time;
  else if (timeUnit.equals(min)) speed = distance*60 / time;
  else speed = distance*3600 / time;
  return new Result(StateDescriptor.OK, SPEED, new Float(speed));
  }
  
  public ParameterDescriptor[] getParameterDescriptors() {
  return parameterDescriptors;
  }
  
  public ResultDescriptor[] getResultDescriptors() {
  return resultDescriptors;
  }
  }
  
  
  1.1  
jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example/SimpleMain.java
  
  Index: SimpleMain.java
  ===
  /*
  *
  * 
  *
  * Copyright 2004 The Apache Software Foundation 
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.
  * You may

cvs commit: jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract - New directory

dflorey 2004/10/08 03:44:53

  jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract - New 
directory

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

cvs commit: jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example - New directory

dflorey 2004/10/08 03:44:53

  jakarta-commons-sandbox/contract/src/examples/org/apache/commons/contract/example - 
New directory

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

[xmlio] New Sandbox component

Hi Folks,

as discussed before I have just added a new component to the sandbox.
xmlio consists of two parts:

(1) low level import from XML to Java via callback (in)
(2) export of XML from Java with low level convenicence methods that
help you create valid XML fast (out)

xmlio is not an XML-Java-Object mapper and it hardly is comparable
with Digester. The import part rather is an extension of SAX that
mainly allows you to have more than one listener, have accumulated
calls and provide the path of the callback.

Documentation, logo, website presence and Marven scripts are still TODOs...

Check out and see if any of this makes sense to you.

Cheers,
Oliver

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

Re: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread Mike Stanley

How does this compare with StAX parser implementations?

- Mike

On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote:

 XMLBeans is super high level, XML Im-/Exporter is super low level.
 E.g. XML Im-/Exporter (silly name by the way, any better ideas?) could
 *theortically* be the base of XMLBeans. It is pretty near to SAX.
 
 Oliver
 
 On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote:
  
  Hi,
  How does this compare to XMLBeans?
  
  Yoav Shapira
  Millennium Research Informatics
  
  
  
  
  -Original Message-
  From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
  Sent: Thursday, October 07, 2004 3:30 PM
  To: [EMAIL PROTECTED]
  Subject: XML Im-/Ex-porter into Commons Sandbox
  
  Folks,
  
  on the request of Daniel Florey I'd like to create at least one new
  sandbox component for a tool that allows easy import / export of XML
  into / from Java. It is used by Jakarta Slide and in the components
  Daniel introduced.
  
  I know this is a bit delicate as there already is Digester around in
  commons. However, the audience for my tool is different from
  Digester's. XML Im-/Exporter is geared towards high performance use
  for people who are very familiar with XML. It is just a little bit
  more than pure SAX. It also has a different philosohie than Digester.
  
  Having said that I hope not to cause any inconvenience with this...
  
  Preparing this now  and cheers,
  
  Oliver
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  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]

Re: XML Im-/Ex-porter into Commons Sandbox

StAX is a new parser type. It is streaming, i.e. you get one token
after the other upon request. xmlio still uses a standard SAX parser
and merely augments callbacks.

Oliver

On Fri, 08 Oct 2004 08:03:36 -0400, Mike Stanley [EMAIL PROTECTED] wrote:
 How does this compare with StAX parser implementations?
 
 - Mike
 
 
 
 On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote:
 
  XMLBeans is super high level, XML Im-/Exporter is super low level.
  E.g. XML Im-/Exporter (silly name by the way, any better ideas?) could
  *theortically* be the base of XMLBeans. It is pretty near to SAX.
 
  Oliver
 
  On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote:
  
   Hi,
   How does this compare to XMLBeans?
  
   Yoav Shapira
   Millennium Research Informatics
  
  
  
  
   -Original Message-
   From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
   Sent: Thursday, October 07, 2004 3:30 PM
   To: [EMAIL PROTECTED]
   Subject: XML Im-/Ex-porter into Commons Sandbox
   
   Folks,
   
   on the request of Daniel Florey I'd like to create at least one new
   sandbox component for a tool that allows easy import / export of XML
   into / from Java. It is used by Jakarta Slide and in the components
   Daniel introduced.
   
   I know this is a bit delicate as there already is Digester around in
   commons. However, the audience for my tool is different from
   Digester's. XML Im-/Exporter is geared towards high performance use
   for people who are very familiar with XML. It is just a little bit
   more than pure SAX. It also has a different philosohie than Digester.
   
   Having said that I hope not to cause any inconvenience with this...
   
   Preparing this now  and cheers,
   
   Oliver
   
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
   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]

cvs commit: jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java/org/apache - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java/org/apache - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/out - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/out - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/test/org/apache - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test/org/apache - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java/org/apache/commons - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java/org/apache/commons - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java/org - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java/org - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/test/org - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test/org - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src - New directory

ozeigermann2004/10/08 04:56:10

  jakarta-commons-sandbox/xmlio/src - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/example - New directory

ozeigermann2004/10/08 04:56:10

  jakarta-commons-sandbox/xmlio/example - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/in - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/in - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/test/org/apache/commons - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test/org/apache/commons - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/src/test - New directory

ozeigermann2004/10/08 04:56:11

  jakarta-commons-sandbox/xmlio/src/test - New directory

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

cvs commit: jakarta-commons-sandbox/xmlio/example Readme.txt

ozeigermann2004/10/08 04:56:20

  Added:   xmlio/src/java/org/apache/commons/xmlio/out
XMLStringWriter.java XMLWriter.java
XMLOutputStreamWriter.java XMLEncode.java
   xmlio/src/java/org/apache/commons/xmlio/in
SimpleImportHandler.java Item.java
DefaultSimpleImportHandler.java SimpleImporter.java
SimpleImporterException.java ConversionHelpers.java
SimplePath.java package.html
   xmlio/src/test/org/apache/commons/xmlio/in
SimpleImportTest.java
   xmliobuild.properties.sample build.xml LICENSE.txt
NOTICE.txt
   xmlio/src/test/org/apache/commons/xmlio/out
XMLWriterTest.java
   xmlio/example Readme.txt
  Log:
  Initial version
  
  Revision  ChangesPath
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLStringWriter.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLStringWriter.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLWriter.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLWriter.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLOutputStreamWriter.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLOutputStreamWriter.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLEncode.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/out/XMLEncode.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimpleImportHandler.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimpleImportHandler.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/Item.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/Item.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/DefaultSimpleImportHandler.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/DefaultSimpleImportHandler.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimpleImporter.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimpleImporter.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimpleImporterException.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimpleImporterException.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/ConversionHelpers.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/ConversionHelpers.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimplePath.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/SimplePath.java?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/package.html
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/java/org/apache/commons/xmlio/in/package.html?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/in/SimpleImportTest.java
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/in/SimpleImportTest.java?rev=1.1
  
  
  1.1  jakarta-commons-sandbox/xmlio/build.properties.sample
  
  
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/build.properties.sample?rev=1.1
  
  
  1.1  jakarta-commons-sandbox/xmlio/build.xml
  
  http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/build.xml?rev=1.1
  
  
  1.1  jakarta-commons-sandbox/xmlio/LICENSE.txt
  
  http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/LICENSE.txt?rev=1.1
  
  
  1.1  jakarta-commons-sandbox/xmlio/NOTICE.txt
  
  http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/xmlio/NOTICE.txt?rev=1.1
  
  
  1.1  
jakarta-commons-sandbox/xmlio/src/test/org/apache/commons/xmlio/out/XMLWriterTest.java

cvs commit: jakarta-commons-sandbox/xmlio - New directory

ozeigermann2004/10/08 04:56:10

  jakarta-commons-sandbox/xmlio - New directory

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

Re: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread Mike Stanley

cool.

I look forward to checking it out.  IMO - that's what a sandbox is
for.  

The dependency issue is a Java problem, not just a Jakarta commons
problem.  

BTW-  There appears to be a lot of xmlio's out there:
http://www.google.com/search?q=xmlio

You may want to consider a different name. 

Also - I know you've received a lot of how does this compare with X
questions, but if you don't mind --- Dom4J ?   (or you can ignore that,
and I'll just wait to see the sandbox and judge for myself --- which I
would inevitably do anyway ;-)

- Mike

On Fri, 2004-10-08 at 08:07, Oliver Zeigermann wrote:

 StAX is a new parser type. It is streaming, i.e. you get one token
 after the other upon request. xmlio still uses a standard SAX parser
 and merely augments callbacks.
 
 Oliver
 
 On Fri, 08 Oct 2004 08:03:36 -0400, Mike Stanley [EMAIL PROTECTED] wrote:
  How does this compare with StAX parser implementations?
  
  - Mike
  
  
  
  On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote:
  
   XMLBeans is super high level, XML Im-/Exporter is super low level.
   E.g. XML Im-/Exporter (silly name by the way, any better ideas?) could
   *theortically* be the base of XMLBeans. It is pretty near to SAX.
  
   Oliver
  
   On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav [EMAIL PROTECTED] wrote:
   
Hi,
How does this compare to XMLBeans?
   
Yoav Shapira
Millennium Research Informatics
   
   
   
   
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 3:30 PM
To: [EMAIL PROTECTED]
Subject: XML Im-/Ex-porter into Commons Sandbox

Folks,

on the request of Daniel Florey I'd like to create at least one new
sandbox component for a tool that allows easy import / export of XML
into / from Java. It is used by Jakarta Slide and in the components
Daniel introduced.

I know this is a bit delicate as there already is Digester around in
commons. However, the audience for my tool is different from
Digester's. XML Im-/Exporter is geared towards high performance use
for people who are very familiar with XML. It is just a little bit
more than pure SAX. It also has a different philosohie than Digester.

Having said that I hope not to cause any inconvenience with this...

Preparing this now  and cheers,

Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
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: [lang] Each Mutable Number class declares Serializable

2004-10-08 Thread David Graham

Just like any other interface child classes inherit it from their parent. 
You can remove the implements Serializable from all Number subclasses. 
They're already Serializable since their parent class is.

David

--- Gary Gregory [EMAIL PROTECTED] wrote:

 Hello,
 
 I see that java.lang.Number declares java.io.Serializable. Number
 subclasses in java.lang do not but each of our Mutable number classes
 does. This does not seem necessary. Am I missing something? Can we
 remove these extra declarations?
 
 Gary
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 




___
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

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

RE: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread Noel J. Bergman

Oliver Zeigermann wrote:

 I understand your fears.

 However, xmlio is not a mapper to Java objects, you just
 receiver augmented SAX call backs.

Is this something that could be pitched to Digester and XMLBeans to use
under the covers?  What would be the pros/cons of their adopting this
package rather than their current code?

--- Noel


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

DO NOT REPLY [Bug 31602] New: - [lang] DateUtils should be able to adjust for weekends, etc.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31602.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31602

[lang] DateUtils should be able to adjust for weekends, etc.

   Summary: [lang] DateUtils should be able to adjust for weekends,
etc.
   Product: Commons
   Version: Nightly Builds
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Lang
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It would be handy if DateUtils could check to see if a given Date fell on a 
weekend (or any particular day.)  It would also be nice to adjust a given date 
until it no longer fell on a particular day of the week.

Following the suggestions from our discussion on the mailing list I have come 
up with some patches.  Please consider them for the DateUtils class.

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

DO NOT REPLY [Bug 31602] - [lang] DateUtils should be able to adjust for weekends, etc.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31602.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31602

[lang] DateUtils should be able to adjust for weekends, etc.





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 14:12 ---
Created an attachment (id=12998)
[PATCH] DateUtils

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

DO NOT REPLY [Bug 31602] - [lang] DateUtils should be able to adjust for weekends, etc.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=31602.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31602

[lang] DateUtils should be able to adjust for weekends, etc.





--- Additional Comments From [EMAIL PROTECTED]  2004-10-08 14:12 ---
Created an attachment (id=12999)
[PATCH] DateUtilsTest

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

Re: [math] Matrix subMatrix and mean methods

2004-10-08 Thread Mark R. Diggory

Brain and Wolfgang,
This sort of clarification is exactly what we needed to hear. It sounds 
like we can begin working portions of Colt now.

My question to Wolfgang is, to avoid fracturing Colt into multiple 
implementations, we could decided between two possible approaches.

A.) Refer to the portions of Colt we may be using by pointing to the 
external Colt project where ever necessary without actually placing the 
entire package into the Apache CVS tree.

or
B.) Explore the idea of Colt as an actual Jakarta level project and 
invite Wolfgang to join us as a member of that project development team.

Wolfgang, what do you think?
thanks,
-Mark
Brian Behlendorf wrote:
On Thu, 7 Oct 2004, Phil Steitz wrote:
Brian Behlendorf wrote:
Thanks, Wolfgang.  This is a pretty easy case for us - as it sits 
today, especially with this email note from Wolfgang (which should be 
included in a NOTES file sitting near colt.jar when imported) it 
looks perfectly fine to incorporate this into Apache, preserving 
CERN's copyright notice. From a policy perspective, we should commit 
to the repository not just the .jar file but the source code as well.

Any patches that Apache developers need to make should be offered 
upstream, of course, and then reincorporated into the ASF repository 
by merging in a new version.  But if we need to locally modify the 
work, then the copyright on the resulting derivative work would be 
(C) Apache Software Foundation and the Apache 2.0 license, being 
careful not to remove the original (C) CERN or license/notice.

What if what we end up wanting to do is to incorporate code from the 
implemented algorithms into existing Apache software?  Then do we just 
need to add the CERN license / notice?

You should include the CERN license into the file where the code that 
originated from CERN appeared, making it clear that it refers to the 
code that was imported.  For example, at the top of the related file:

/* Copyright 1999-2004 The Apache Software Foundation
 *
 * Licensed under the Apache License, Version 2.0 (the License);
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
/* Portions originally Copyright CERN, under the following license:
 * [... CERN license ...]
 */
The CVS or SVN history would be consulted if we needed to know exactly 
which portions.  The above is enough to know - it gives credit where 
credit is due, and nothing in that license places a requirement that the 
ASF license does not also require.

Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [xmlio] New Sandbox component

2004-10-08 Thread John Kristian

I'm to blame for Beck.  Sorry I haven't reviewed xmlio yet.  From your
description it sounds like Beck and xmlio have rather different aims.
But they're close enough relatives that we might benefit from
cross-pollination.  I'd be happy to compare notes, if you like.

By the way, can you recommend any tools for mapping between XML and Java
(in both directions)?  I was driven to create Beck because I couldn't find
anything adequate.  But I'd be delighted to use something off the shelf, if
it did what I need.

- John Kristian


- Original Message - 
From: Oliver Zeigermann [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, October 08, 2004 3:36 AM
Subject: Re: XML Im-/Ex-porter into Commons Sandbox

 Ah, now I understand your fears. Just another XML-Java mapper flying
 around ih the user list: http://beck.sourceforge.net/. However,
 xmlio is not a mapper to Java objects, you just receiver augmented SAX
 call backs. Enough talk, I will prepare something now...

 Oliver

- Original Message - 
From: Oliver Zeigermann [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 08, 2004 4:57 AM
Subject: [xmlio] New Sandbox component

 Hi Folks,

 as discussed before I have just added a new component to the sandbox.
 xmlio consists of two parts:

 (1) low level import from XML to Java via callback (in)
 (2) export of XML from Java with low level convenicence methods that
 help you create valid XML fast (out)

 xmlio is not an XML-Java-Object mapper and it hardly is comparable
 with Digester. The import part rather is an extension of SAX that
 mainly allows you to have more than one listener, have accumulated
 calls and provide the path of the callback.

 Documentation, logo, website presence and Marven scripts are still
TODOs...

 Check out and see if any of this makes sense to you.

 Cheers,
 Oliver


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

Re: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread James Mitchell

I actually have no opinion about having multiple libraries that (almost)
server the same purpose, but with regards to the i18n project, I plan to add
the ability to tell it to use Digester (instead of the default) so you won't
actually need xmlio.


--
James Mitchell
Software Engineer / Open Source Evangelist
EdgeTech, Inc.
678.910.8017
AIM: jmitchtx

- Original Message -
From: Daniel Florey [EMAIL PROTECTED]
To: 'Jakarta Commons Developers List' [EMAIL PROTECTED];
'Martin Cooper' [EMAIL PROTECTED]
Sent: Friday, October 08, 2004 4:31 AM
Subject: AW: XML Im-/Ex-porter into Commons Sandbox


Hi all,
I'll have a look at Digester again today and will compare the two approaches
finally for use in i18n.
As I know Oliver Zeigermann for a long time and he really is the master of
xml/sgml I everyone should give xmlio (good name indeed) a try.
Personally I like technologies that keep it very simple so that you
understand at the first sight what's going on without hiding too much
implicit logic.
As I stated earlier we have used Digester in a large project where a lot xml
parsing took place and we had some trouble with it (but that's some time
ago).
So I'd vote for putting the xmlio into the sandbox and let everybody have a
look at it. Even if it will never make it to commons components, it is worth
to have a look at its simplicity.
Regards,
Daniel


-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im
Auftrag von Martin Cooper
Gesendet: Donnerstag, 7. Oktober 2004 23:46
An: Jakarta Commons Developers List
Betreff: Re: XML Im-/Ex-porter into Commons Sandbox

On Thu, 7 Oct 2004 23:27:39 +0100, Stephen Colebourne
[EMAIL PROTECTED] wrote:
 One of the key items in the commons charter is allowing different
solutions
 to the same problem. So far, we have tended to avoid this (for example, I
 took a conflicting primitives design elsewhere) however we should not
block
 this.

 What is being requested at this point is to factor out some code from
 another project (Slide) to commons. This is IMHO perfectly good and what
 commons is for. The code is going to the sandbox where we can all
determine
 whether it is a good addition to the commons-proper fold. (eg. performance
 tests, code design, documentation). Who knows maybe the ideas will end up
as
 digester 2! IMO thats what the sandbox is for.

In general, I agree with you. However, in this case, the reason for
bringing this component to the sandbox is because another component
that has only just arrived in the sandbox (i18n) wants to use it
instead of Digester. It seems that this XML component wasn't going to
be brought to Commons (at least for the moment) until there was
mention that i18n wanted to use it.

I'm not sure that I like the idea of new sandbox components bringing
along other components as baggage when there is already suitable
functionality available in Commons Proper. On the other hand, I would
not be opposed to bringing the XML component in _later_, and letting
it stand or fall on its own.

--
Martin Cooper



 BTW, I don't disagree with the comments about bad dependency management
 below, I just disagree that that necessarily implies only ever supporting
 digester.

 Finally, the name ;-)
 xmlio  (ie. xml io)
 sax
 saxio

 Typically, the commons project is named after the technology it works on.
 Without having seen the code its also difficult to judge what a good name
 would be ;-) I quite like xmlio myself.

 Stephen



 - Original Message -
 From: David Graham [EMAIL PROTECTED]
  This will create bloat problems for clients that use Digester.  For
  example:  Struts uses Digester for xml parsing.  In the future Struts
may
  want to use the new i18n component.  However, if i18n uses XML
Im-Exporter
  then Struts must drag that along too despite already having a perfectly
  fine xml parser in its dependency list.
 
  Struts is just one example.  It will be even worse for inter-commons
  project dependencies.
 
  Bad dependency management has plagued commons components and it's just
  recently started to get better.  If all commons components use Digester
  then we can avoid having to duplicate functionality and bloat
  dependencies.
 
  I don't understand what's wrong with Digester that necessitates a new
  parsing library.  I've been able to write complex parsing rules in a
  matter of minutes.
 
  David
 
  --- Oliver Zeigermann [EMAIL PROTECTED] wrote:
 
   Folks,
  
   on the request of Daniel Florey I'd like to create at least one new
   sandbox component for a tool that allows easy import / export of XML
   into / from Java. It is used by Jakarta Slide and in the components
   Daniel introduced.
  
   I know this is a bit delicate as there already is Digester around in
   commons. However, the audience for my tool is different from
   Digester's. XML Im-/Exporter is geared towards high performance use
   for people who are very familiar with XML. It is just a little bit
   more than pure SAX. It also has a

Re: [xmlio] New Sandbox component

In case anyone cares 

org.apache.commons.xmlio.in.SimpleImportHandler

might be a good place to start with XML-Java.

Maybe Daniel would donate some examples For now the junit test in src/test 

org.apache.commons.xmlio.in.SimpleImportTest

shows how to use it. 

Compared to may ordinary lazyness, Javadocs are pretty good as well...

Oliver

On Fri, 8 Oct 2004 13:57:04 +0200, Oliver Zeigermann
[EMAIL PROTECTED] wrote:
 Hi Folks,
 
 as discussed before I have just added a new component to the sandbox.
 xmlio consists of two parts:
 
 (1) low level import from XML to Java via callback (in)
 (2) export of XML from Java with low level convenicence methods that
 help you create valid XML fast (out)
 
 xmlio is not an XML-Java-Object mapper and it hardly is comparable
 with Digester. The import part rather is an extension of SAX that
 mainly allows you to have more than one listener, have accumulated
 calls and provide the path of the callback.
 
 Documentation, logo, website presence and Marven scripts are still TODOs...
 
 Check out and see if any of this makes sense to you.
 
 Cheers,
 Oliver


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

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/builder PatternBuilder.java DefaultOptionBuilder.java CommandBuilder.java GroupBuilder.java ArgumentBuilder.java SwitchBuilder.java

roxspring2004/10/08 09:35:34

  Modified:cli/src/java/org/apache/commons/cli2/builder
PatternBuilder.java DefaultOptionBuilder.java
CommandBuilder.java GroupBuilder.java
ArgumentBuilder.java SwitchBuilder.java
  Log:
  *Builder.reset() now returns this builder instance
  
  Revision  ChangesPath
  1.3   +2 -1  
jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/PatternBuilder.java
  
  Index: PatternBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/PatternBuilder.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- PatternBuilder.java   22 Apr 2004 23:00:15 -  1.2
  +++ PatternBuilder.java   8 Oct 2004 16:35:34 -   1.3
  @@ -91,8 +91,9 @@
   /**
* Resets this builder
*/
  -public void reset() {
  +public PatternBuilder reset() {
   options.clear();
  +return this;
   }
   
   private void createOption(
  
  
  
  1.4   +2 -1  
jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/DefaultOptionBuilder.java
  
  Index: DefaultOptionBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/DefaultOptionBuilder.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- DefaultOptionBuilder.java 7 Sep 2004 00:18:24 -   1.3
  +++ DefaultOptionBuilder.java 8 Oct 2004 16:35:34 -   1.4
  @@ -116,7 +116,7 @@
   /**
* Resets the builder
*/
  -public void reset() {
  +public DefaultOptionBuilder reset() {
   preferredName = null;
   description = null;
   aliases = new HashSet();
  @@ -125,6 +125,7 @@
   argument = null;
   children = null;
   id = 0;
  +return this;
   }
   
   /**
  
  
  
  1.3   +2 -1  
jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/CommandBuilder.java
  
  Index: CommandBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/CommandBuilder.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CommandBuilder.java   22 Apr 2004 23:00:15 -  1.2
  +++ CommandBuilder.java   8 Oct 2004 16:35:34 -   1.3
  @@ -76,7 +76,7 @@
* Resets the CommandBuilder to the defaults for a new Command. The method
* should be called automatically at the end of a create() call.
*/
  -public void reset() {
  +public CommandBuilder reset() {
   preferredName = null;
   description = null;
   aliases = new HashSet();
  @@ -84,6 +84,7 @@
   argument = null;
   children = null;
   id = 0;
  +return this;
   }
   
   /**
  
  
  
  1.3   +2 -1  
jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/GroupBuilder.java
  
  Index: GroupBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/GroupBuilder.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- GroupBuilder.java 22 Apr 2004 23:00:15 -  1.2
  +++ GroupBuilder.java 8 Oct 2004 16:35:34 -   1.3
  @@ -56,12 +56,13 @@
   /**
* Resets the builder
*/
  -public void reset() {
  +public GroupBuilder reset() {
   name = null;
   description = null;
   options = new ArrayList();
   minimum = 0;
   maximum = Integer.MAX_VALUE;
  +return this;
   }
   
   /**
  
  
  
  1.4   +2 -1  
jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/ArgumentBuilder.java
  
  Index: ArgumentBuilder.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/builder/ArgumentBuilder.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ArgumentBuilder.java  2 Oct 2004 11:35:34 -   1.3
  +++ ArgumentBuilder.java  8 Oct 2004 16:35:34 -   1.4
  @@ -93,7 +93,7 @@
* Resets the ArgumentBuilder to the defaults for a new Argument. The
* method should be called automatically at the end of a create() call.
*/
  -public final void reset() {
  +public final ArgumentBuilder reset() {
   name = arg;
   description = null;
   minimum = 0;
  @@ -104,6 +104,7 @@
   consumeRemaining = --;
   defaultValues = null;
   id = 0;
  +return this;
   }

[GUMP@brutus]: Project commons-resources (in Module jakarta-commons-sandbox) failed

2004-10-08 Thread Stefan Bodewig

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-resources has an issue affecting its community integration.
This issue affects 1 projects.
Project State : 'Failed'
The following are affected:
- commons-resources :  Commons resources


Full details are available at:


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

That said, some snippets follow:


The following annotations were provided:
 -DEBUG- Sole output [commons-resources-08102004.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository


The following work was performed:
http://brutus.apache.org/gump/public/jakarta-commons-sandbox/commons-resources/gump_work/build_jakarta-commons-sandbox_commons-resources.html
Work Name: build_jakarta-commons-sandbox_commons-resources (Type: Build)
State: Failed
Elapsed: 3 secs
Command Line: java -Djava.awt.headless=true -Dbuild.clonevm=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:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dfinal.name=commons-resources-08102004 dist 
[Working Directory: /usr/local/gump/public/workspace/jakarta-commons-sandbox/resources]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes:/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/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/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-08102004.jar:/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar:/usr/local/gump/public/workspace/jakarta-commons/discovery/dist/commons-discovery.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-dao-2.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-common-2.jar:/usr/local/gump/packages/iBATIS_DBL-2.0.5.399/ibatis-sqlmap-2.jar-
Buildfile: build.xml

init:
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/lib

get-deps:

compile:
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes
[javac] Compiling 28 source files to 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/target/classes
[javac] 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:38:
 package com.ibatis.db.sqlmap does not exist
[javac] import com.ibatis.db.sqlmap.SqlMap;
[javac] ^
[javac] 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:39:
 package com.ibatis.db.sqlmap does not exist
[javac] import com.ibatis.db.sqlmap.XmlSqlMapBuilder;
[javac] ^
[javac] 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:64:
 cannot resolve symbol
[javac] symbol  : class SqlMap 
[javac] location: class org.apache.commons.resources.impl.IBatisResources
[javac] protected static SqlMap sqlMap;
[javac]  ^
[javac] 
/usr/local/gump/public/workspace/jakarta-commons-sandbox/resources/src/java/org/apache/commons/resources/impl/IBatisResources.java:135:
 cannot resolve symbol
[javac] symbol  : variable XmlSqlMapBuilder 
[javac] location: class org.apache.commons.resources.impl.IBatisResources
[javac] sqlMap = XmlSqlMapBuilder.buildSqlMap(reader);
[javac]

RE: [math] Matrix subMatrix and mean methods

2004-10-08 Thread Phil Steitz

Mark,
 
We should discuss this as part of post 1.0 planning for [math].  There is a third 
option, which is to borrow code from Colt as we implement the kinds of pluggable 
numerical linear algebra implementations that we have been discussing.  Maybe that is 
what you mean by fracturing.  Probably not the best way to go, but may be necessary 
to maintain performance + flexibility.  
 
Regarding Colt as a Jakarta subproject, or as part of a larger Jakarta or Apache Math 
project, that is an interesting idea.  This would probably need to go through the 
incubator.  Is http://dsd.lbl.gov/~hoschek/colt/index.html the right project page for 
the current development in Colt?  Is the mailing list referenced there active? 
 
Phil

-Original Message- 
From: Mark R. Diggory [mailto:[EMAIL PROTECTED] 
Sent: Fri 10/8/2004 7:19 AM 
To: Jakarta Commons Developers List 
Cc: [EMAIL PROTECTED]; Wolfgang Hoschek 
Subject: Re: [math] Matrix subMatrix and mean methods



Brain and Wolfgang,

This sort of clarification is exactly what we needed to hear. It sounds
like we can begin working portions of Colt now.

My question to Wolfgang is, to avoid fracturing Colt into multiple
implementations, we could decided between two possible approaches.

A.) Refer to the portions of Colt we may be using by pointing to the
external Colt project where ever necessary without actually placing the
entire package into the Apache CVS tree.

or

B.) Explore the idea of Colt as an actual Jakarta level project and
invite Wolfgang to join us as a member of that project development team.

Wolfgang, what do you think?

thanks,
-Mark

Brian Behlendorf wrote:
 On Thu, 7 Oct 2004, Phil Steitz wrote:

 Brian Behlendorf wrote:


 Thanks, Wolfgang.  This is a pretty easy case for us - as it sits
 today, especially with this email note from Wolfgang (which should be
 included in a NOTES file sitting near colt.jar when imported) it
 looks perfectly fine to incorporate this into Apache, preserving
 CERN's copyright notice. From a policy perspective, we should commit
 to the repository not just the .jar file but the source code as well.

 Any patches that Apache developers need to make should be offered
 upstream, of course, and then reincorporated into the ASF repository
 by merging in a new version.  But if we need to locally modify the
 work, then the copyright on the resulting derivative work would be
 (C) Apache Software Foundation and the Apache 2.0 license, being
 careful not to remove the original (C) CERN or license/notice.


 What if what we end up wanting to do is to incorporate code from the
 implemented algorithms into existing Apache software?  Then do we just
 need to add the CERN license / notice?


 You should include the CERN license into the file where the code that
 originated from CERN appeared, making it clear that it refers to the
 code that was imported.  For example, at the top of the related file:

 /* Copyright 1999-2004 The Apache Software Foundation
  *
  * Licensed under the Apache License, Version 2.0 (the License);
  * you may not use this file except in compliance with the License.
  * You may obtain a copy of the License at
  *
  * http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an AS IS BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */

 /* Portions originally Copyright CERN, under the following license:
  * [... CERN license ...]
  */

 The CVS or SVN history would be consulted if we needed to know exactly
 which portions.  The above is enough to know - it gives credit where
 credit is due, and nothing in that license places a requirement that the
 ASF license does not also require.

 Brian


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


--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org

Re: [math] Matrix subMatrix and mean methods

2004-10-08 Thread Wolfgang Hoschek

Mark,
I am not worried about fracturing. My understanding is that you 
wouldn't start doing colt releases build by apache, right? You'd rather 
take some parts or derivatives of the code and add them to commons-math 
CVS as you see fit (probably in a significantly refactored/modified 
form). I thought that was the overall idea, and it seems to me a good 
one.

If all goes well, Colt as an external library could fade into oblivion 
in a year or two, or whatever time it takes for math to really shape 
up. That's absolutely fine with me.

As far as myself as project member/committer: Thanks for the kind 
invitation, but I'm really busy with other things these days. However, 
I can be there for you in case you'd have questions about how/why 
things work the way they work in colt. To reach me, please make sure 
to cc me; commons-dev is a high volume mailing list.

I have no particular opinion on (A), it's up to you.
B) sounds confusing to me as it might indicate to users that they 
should use that library instead of commons-math. Why have a jakarta 
level project if all you want is to take some parts or derivatives of 
it and integrate them in math?

Regards,
Wolfgang.
Mark, see comments inline below:
On Oct 8, 2004, at 7:19 AM, Mark R. Diggory wrote:
Brain and Wolfgang,
This sort of clarification is exactly what we needed to hear. It 
sounds like we can begin working portions of Colt now.

My question to Wolfgang is, to avoid fracturing Colt into multiple 
implementations, we could decided between two possible approaches.

A.) Refer to the portions of Colt we may be using by pointing to the 
external Colt project where ever necessary without actually placing 
the entire package into the Apache CVS tree.

or
B.) Explore the idea of Colt as an actual Jakarta level project and 
invite Wolfgang to join us as a member of that project development 
team.

Wolfgang, what do you think?


thanks,
-Mark
Brian Behlendorf wrote:
On Thu, 7 Oct 2004, Phil Steitz wrote:
Brian Behlendorf wrote:
Thanks, Wolfgang.  This is a pretty easy case for us - as it sits 
today, especially with this email note from Wolfgang (which should 
be included in a NOTES file sitting near colt.jar when imported) it 
looks perfectly fine to incorporate this into Apache, preserving 
CERN's copyright notice. From a policy perspective, we should 
commit to the repository not just the .jar file but the source code 
as well.

Any patches that Apache developers need to make should be offered 
upstream, of course, and then reincorporated into the ASF 
repository by merging in a new version.  But if we need to locally 
modify the work, then the copyright on the resulting derivative 
work would be (C) Apache Software Foundation and the Apache 2.0 
license, being careful not to remove the original (C) CERN or 
license/notice.

What if what we end up wanting to do is to incorporate code from the 
implemented algorithms into existing Apache software?  Then do we 
just need to add the CERN license / notice?
You should include the CERN license into the file where the code that 
originated from CERN appeared, making it clear that it refers to the 
code that was imported.  For example, at the top of the related file:
/* Copyright 1999-2004 The Apache Software Foundation
 *
 * Licensed under the Apache License, Version 2.0 (the License);
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an AS IS BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */
/* Portions originally Copyright CERN, under the following license:
 * [... CERN license ...]
 */
The CVS or SVN history would be consulted if we needed to know 
exactly which portions.  The above is enough to know - it gives 
credit where credit is due, and nothing in that license places a 
requirement that the ASF license does not also require.
Brian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org

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

Re: [math] Matrix subMatrix and mean methods

2004-10-08 Thread Mark R. Diggory

Phil Steitz wrote:
Mark,

We should discuss this as part of post 1.0 planning for [math]. There is a third option, which is to borrow code from Colt as we implement the kinds of pluggable numerical linear algebra implementations that we have been discussing. Maybe that is what you mean by fracturing. Probably not the best way to go, but may be necessary to maintain performance + flexibility.

Actually, what I mean by fracturing is creating two separate complete
versions of Colt (one Apache, one Not) occupying the same package name
space, this would be a problem (as Wolfgang pointed out too). This would
be bad in that both these projects, already having small development
communities would become competitive and conflicting instead of cooperative.

I don't think that borrowing portions of implementation from Colt is
fracturing as the Commons Math is already a separate project, we are
just adding in functionality to an already existing API.

Regarding Colt as a Jakarta subproject, or as part of a larger Jakarta or Apache Math project, that is an interesting idea. This would probably need to go through the incubator.

I would suspect so too. But it is a relatively mature project on its own
so incubation would probably be a short process, mainly to organize the
development team and manage any donation/licensing sort of issues.

Wolfgang just gracefully declined to be a developer in such a project
at Apache. So that effects (or doesn't) what we do decide to do now.

Is http://dsd.lbl.gov/~hoschek/colt/index.html the right project page for the current development in Colt? Is the mailing list referenced there active?

Yes, I am on the list currently, there is some activity.
Phil
-Original Message-
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Fri 10/8/2004 7:19 AM
To: Jakarta Commons Developers List
Cc: [EMAIL PROTECTED]; Wolfgang Hoschek
Subject: Re: [math] Matrix subMatrix and mean methods

Brain and Wolfgang,

This sort of clarification is exactly what we needed to hear. It sounds
like we can begin working portions of Colt now.

My question to Wolfgang is, to avoid fracturing Colt into multiple
implementations, we could decided between two possible approaches.

A.) Refer to the portions of Colt we may be using by pointing to the
external Colt project where ever necessary without actually placing the
entire package into the Apache CVS tree.

B.) Explore the idea of Colt as an actual Jakarta level project and
invite Wolfgang to join us as a member of that project development team.

Wolfgang, what do you think?

thanks,
-Mark

Brian Behlendorf wrote:
On Thu, 7 Oct 2004, Phil Steitz wrote:

Brian Behlendorf wrote:

Thanks, Wolfgang. This is a pretty easy case for us - as it sits
today, especially with this email note from Wolfgang (which should be
included in a NOTES file sitting near colt.jar when imported) it
looks perfectly fine to incorporate this into Apache, preserving
CERN's copyright notice. From a policy perspective, we should commit
to the repository not just the .jar file but the source code as well.

Any patches that Apache developers need to make should be offered
upstream, of course, and then reincorporated into the ASF repository
by merging in a new version. But if we need to locally modify the
work, then the copyright on the resulting derivative work would be
(C) Apache Software Foundation and the Apache 2.0 license, being
careful not to remove the original (C) CERN or license/notice.

What if what we end up wanting to do is to incorporate code from the
implemented algorithms into existing Apache software? Then do we just
need to add the CERN license / notice?

You should include the CERN license into the file where the code that
originated from CERN appeared, making it clear that it refers to the
code that was imported. For example, at the top of the related file:

/* Copyright 1999-2004 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific

Re: [math] Matrix subMatrix and mean methods

2004-10-08 Thread Mark R. Diggory


Wolfgang Hoschek wrote:
Mark,
I am not worried about fracturing. My understanding is that you 
wouldn't start doing colt releases build by apache, right? You'd rather 
take some parts or derivatives of the code and add them to commons-math 
CVS as you see fit (probably in a significantly refactored/modified 
form). I thought that was the overall idea, and it seems to me a good one.
We have discussed a Larger project at Apache that would be more 
expansive than what is currently capable in the Jakarta Commons. 
Whether or not such a project takes off has been limited more by 
uncertainty of what its boundaries would be.

If all goes well, Colt as an external library could fade into oblivion 
in a year or two, or whatever time it takes for math to really shape up. 
That's absolutely fine with me.
Do you suspect that you or CERN will maintain historical archiving of 
the Colt project indefinitely if it did? This is one of the 
characteristics of ASF, we maintain historical CVS and distribution 
archives for all the projects that have existed in Apache. So, if Colt 
moved into Apache, it would have a long term, canonical archival home 
for its existence even if it's contents were integrated into Apache 
Math. If it was not your interest to maintain it any longer, then such 
an option would be beneficial for the both historical referencing and 
reusage.
As far as myself as project member/committer: Thanks for the kind 
invitation, but I'm really busy with other things these days. However, I 
can be there for you in case you'd have questions about how/why things 
work the way they work in colt. To reach me, please make sure to cc 
me; commons-dev is a high volume mailing list.
Of course, we would enjoy any involvement you can provide. I understand 
your career focus may be in different directions now.

I have no particular opinion on (A), it's up to you.
B) sounds confusing to me as it might indicate to users that they should 
use that library instead of commons-math. Why have a jakarta level 
project if all you want is to take some parts or derivatives of it and 
integrate them in math?

Regards,
Wolfgang.
Codebases have been donated to Apache Jakarta in the past which maintain 
similar capabilities. For instance, Oro and Apache Regexp were projects 
from different development groups, the code donation was to, in my 
belief, provide a mechanism to merge these projects at a time in the 
future, taking the best of both worlds.

http://jakarta.apache.org/oro/index.html
http://jakarta.apache.org/regexp/index.html
I do adimately believe we would not want to consider releasing a full 
version of Colt unless you were interested in migrating the entire 
project into Apache, this is what I mean by fracturing, we do not want 
to see two separate Colt communities competing for membership, this 
would not be in either of our interests, would confuse the userbase and 
not allow us to build a shared development community.

thanks,
Mark
--
Mark Diggory
Open Source Software Developer
Apache Jakarta Project
http://jakarta.apache.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [lang] Each Mutable Number class declares Serializable

2004-10-08 Thread Gary Gregory

Right, so unless I hear otherwise, I will clean this up over the
weekend.

Thanks,
Gary

 -Original Message-
 From: David Graham [mailto:[EMAIL PROTECTED]
 Sent: Friday, October 08, 2004 06:16
 To: Jakarta Commons Developers List
 Subject: Re: [lang] Each Mutable Number class declares Serializable

 Just like any other interface child classes inherit it from their
parent.
 You can remove the implements Serializable from all Number
subclasses.
 They're already Serializable since their parent class is.

 David

 --- Gary Gregory [EMAIL PROTECTED] wrote:

  Hello,

  I see that java.lang.Number declares java.io.Serializable. Number
  subclasses in java.lang do not but each of our Mutable number
classes
  does. This does not seem necessary. Am I missing something? Can we
  remove these extra declarations?

  Gary

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

 ___
 Do you Yahoo!?
 Declare Yourself - Register online to vote today!
 http://vote.yahoo.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: XML Im-/Ex-porter into Commons Sandbox

2004-10-08 Thread Gary Gregory

Hello,

I would like to suggest that we find a better name for this project. It
seems the key is that it augments callbacks for SAX. So maybe a name
that tries to convey this fact:

- SaxEx
- Sax???

Gary

 -Original Message-
 From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
 Sent: Friday, October 08, 2004 05:08
 To: Jakarta Commons Developers List; [EMAIL PROTECTED]
 Subject: Re: XML Im-/Ex-porter into Commons Sandbox
 
 StAX is a new parser type. It is streaming, i.e. you get one token
 after the other upon request. xmlio still uses a standard SAX parser
 and merely augments callbacks.
 
 Oliver
 
 On Fri, 08 Oct 2004 08:03:36 -0400, Mike Stanley
[EMAIL PROTECTED]
 wrote:
  How does this compare with StAX parser implementations?
 
  - Mike
 
 
 
  On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote:
 
   XMLBeans is super high level, XML Im-/Exporter is super low level.
   E.g. XML Im-/Exporter (silly name by the way, any better ideas?)
could
   *theortically* be the base of XMLBeans. It is pretty near to SAX.
  
   Oliver
  
   On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav
 [EMAIL PROTECTED] wrote:
   
Hi,
How does this compare to XMLBeans?
   
Yoav Shapira
Millennium Research Informatics
   
   
   
   
-Original Message-
From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 07, 2004 3:30 PM
To: [EMAIL PROTECTED]
Subject: XML Im-/Ex-porter into Commons Sandbox

Folks,

on the request of Daniel Florey I'd like to create at least one
new
sandbox component for a tool that allows easy import / export
of
 XML
into / from Java. It is used by Jakarta Slide and in the
components
Daniel introduced.

I know this is a bit delicate as there already is Digester
around
 in
commons. However, the audience for my tool is different from
Digester's. XML Im-/Exporter is geared towards high performance
use
for people who are very familiar with XML. It is just a little
bit
more than pure SAX. It also has a different philosohie than
 Digester.

Having said that I hope not to cause any inconvenience with
this...

Preparing this now  and cheers,

Oliver

   
---
 --
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail: commons-dev-
 [EMAIL PROTECTED]
   
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]


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

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/option PropertyOption.java

roxspring2004/10/08 12:41:19

  Modified:cli/src/java/org/apache/commons/cli2/option
PropertyOption.java
  Log:
  Made default constants public
  
  Revision  ChangesPath
  1.3   +2 -2  
jakarta-commons/cli/src/java/org/apache/commons/cli2/option/PropertyOption.java
  
  Index: PropertyOption.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/cli/src/java/org/apache/commons/cli2/option/PropertyOption.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- PropertyOption.java   22 Apr 2004 23:00:07 -  1.2
  +++ PropertyOption.java   8 Oct 2004 19:41:18 -   1.3
  @@ -31,8 +31,8 @@
*/
   public class PropertyOption extends OptionImpl {
   
  -private static final String DEFAULT_OPTION_STRING = -D;
  -private static final String DEFAULT_DESCRIPTION =
  +public static final String DEFAULT_OPTION_STRING = -D;
  +public static final String DEFAULT_DESCRIPTION =
   Passes properties and values to the application;
   
   private final String optionString;
  
  
  

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

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html MutableFloat.java MutableByte.java MutableShort.java MutableObject.java MutableLong.java MutableInt.java MutableDouble.java Mutable.java

2004-10-08 Thread ggregory

ggregory2004/10/08 12:45:46

  Modified:lang/src/java/org/apache/commons/lang/mutable
MutableFloat.java MutableByte.java
MutableShort.java MutableObject.java
MutableLong.java MutableInt.java MutableDouble.java
Mutable.java
  Added:   lang/src/java/org/apache/commons/lang/mutable package.html
  Log:
  - Added javadoc package.html
  - Removed all implements java.io.Serializable since java.lang.Number already 
declares it.
  - New Javadoc for equals(Object) methods to match Number subclasses, in particular 
to provide more details for Float and Double.
  - equals(Object) methods now use /type/Value() calls instead of .value direct 
references (similar impl to Number subclasses).
  
  Revision  ChangesPath
  1.6   +74 -29
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableFloat.java
  
  Index: MutableFloat.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableFloat.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- MutableFloat.java 1 Oct 2004 17:12:29 -   1.5
  +++ MutableFloat.java 8 Oct 2004 19:45:46 -   1.6
  @@ -13,20 +13,19 @@
* See the License for the specific language governing permissions and
* limitations under the License.
*/
  -package org.apache.commons.lang.mutable;
   
  -import java.io.Serializable;
  +package org.apache.commons.lang.mutable;
   
   import org.apache.commons.lang.math.NumberUtils;
   
   /**
  - * A mutable codefloat/code.
  + * A mutable codefloat/code wrapper.
* 
  + * @see Float
* @since 2.1
* @version $Id$
*/
  -public class MutableFloat extends Number
  -implements Comparable, Mutable, Serializable {
  +public class MutableFloat extends Number implements Comparable, Mutable {
   
   /** Serialization lock. */
   private static final long serialVersionUID = 5787169186L;
  @@ -44,7 +43,8 @@
   /**
* Constructs a new MutableFloat with the specified value.
* 
  - * @param value a value.
  + * @param value
  + *a value.
*/
   public MutableFloat(float value) {
   super();
  @@ -54,8 +54,10 @@
   /**
* Constructs a new MutableFloat with the specified value.
* 
  - * @param value a value.
  - * @throws NullPointerException if the object is null
  + * @param value
  + *a value.
  + * @throws NullPointerException
  + * if the object is null
*/
   public MutableFloat(Number value) {
   super();
  @@ -75,7 +77,8 @@
   /**
* Sets the value.
* 
  - * @param value  the value to set
  + * @param value
  + *the value to set
*/
   public void setValue(float value) {
   this.value = value;
  @@ -84,9 +87,12 @@
   /**
* Sets the value from any Number instance.
* 
  - * @param value  the value to set
  - * @throws NullPointerException if the object is null
  - * @throws ClassCastException if the type is invalid
  + * @param value
  + *the value to set
  + * @throws NullPointerException
  + * if the object is null
  + * @throws ClassCastException
  + * if the type is not a [EMAIL PROTECTED] Number}
*/
   public void setValue(Object value) {
   setValue(((Number) value).floatValue());
  @@ -111,7 +117,7 @@
   
   /**
* Checks whether the float value is the special NaN value.
  - *
  + * 
* @return true if NaN
*/
   public boolean isNaN() {
  @@ -120,33 +126,71 @@
   
   /**
* Checks whether the float value is infinite.
  - *
  + * 
* @return true if infinite
*/
   public boolean isInfinite() {
   return Float.isInfinite(value);
   }
   
  +/**
  + * Compares this object against some other object. The result is 
codetrue/code if and only if the argument is
  + * not codenull/code and is a codeFloat/code object that represents a 
codefloat/code that has the
  + * identical bit pattern to the bit pattern of the codefloat/code 
represented by this object. For this
  + * purpose, two float values are considered to be the same if and only if the 
method
  + * [EMAIL PROTECTED] Float#floatToIntBits(float)}returns the same int value 
when applied to each.
  + * p
  + * Note that in most cases, for two instances of class 
codeFloat/code,codef1/code and codef2/code,
  + * the value of codef1.equals(f2)/code is codetrue/code if and only if 
blockquote
  + * 
  + * pre
  + *   f1.floatValue() == f2.floatValue()
  + * /pre
  + * 
  + * /blockquote
  + * p
  + * also has the value

Re: XML Im-/Ex-porter into Commons Sandbox

Augmenting sax is only the in part. The out part has got nothing
to do with sax. Actually, except for the attributes and call back
nature it does not look like sax anymore. So, I guess xmlio isn't that
bad, is it? Even though it is not realy original...

Oliver

On Fri, 8 Oct 2004 15:08:55 -0400, Gary Gregory
[EMAIL PROTECTED] wrote:
 Hello,
 
 I would like to suggest that we find a better name for this project. It
 seems the key is that it augments callbacks for SAX. So maybe a name
 that tries to convey this fact:
 
 - SaxEx
 - Sax???
 
 Gary
 
  -Original Message-
  From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
  Sent: Friday, October 08, 2004 05:08
  To: Jakarta Commons Developers List; [EMAIL PROTECTED]
  Subject: Re: XML Im-/Ex-porter into Commons Sandbox
 
  StAX is a new parser type. It is streaming, i.e. you get one token
  after the other upon request. xmlio still uses a standard SAX parser
  and merely augments callbacks.
 
  Oliver
 
  On Fri, 08 Oct 2004 08:03:36 -0400, Mike Stanley
 [EMAIL PROTECTED]
  wrote:
   How does this compare with StAX parser implementations?
  
   - Mike
  
  
  
   On Thu, 2004-10-07 at 15:53, Oliver Zeigermann wrote:
  
XMLBeans is super high level, XML Im-/Exporter is super low level.
E.g. XML Im-/Exporter (silly name by the way, any better ideas?)
 could
*theortically* be the base of XMLBeans. It is pretty near to SAX.
   
Oliver
   
On Thu, 7 Oct 2004 15:38:10 -0400, Shapira, Yoav
  [EMAIL PROTECTED] wrote:

 Hi,
 How does this compare to XMLBeans?

 Yoav Shapira
 Millennium Research Informatics




 -Original Message-
 From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
 Sent: Thursday, October 07, 2004 3:30 PM
 To: [EMAIL PROTECTED]
 Subject: XML Im-/Ex-porter into Commons Sandbox
 
 Folks,
 
 on the request of Daniel Florey I'd like to create at least one
 new
 sandbox component for a tool that allows easy import / export
 of
  XML
 into / from Java. It is used by Jakarta Slide and in the
 components
 Daniel introduced.
 
 I know this is a bit delicate as there already is Digester
 around
  in
 commons. However, the audience for my tool is different from
 Digester's. XML Im-/Exporter is geared towards high performance
 use
 for people who are very familiar with XML. It is just a little
 bit
 more than pure SAX. It also has a different philosohie than
  Digester.
 
 Having said that I hope not to cause any inconvenience with
 this...
 
 Preparing this now  and cheers,
 
 Oliver
 

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

 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]
 
 
 -
 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: [sandbox-workflow] What is the status of this project?

2004-10-08 Thread Craig McClanahan

On Thu, 07 Oct 2004 17:19:23 -0400, Sean Schofield
[EMAIL PROTECTED] wrote:
 Is there any serious work going on with workflow?  I have developed a
 complete workflow package and have a lot of ideas I could contribute.
 If there's anyone out there on the list interested in discussing I am
 available.

The [workflow] package in the Commons Sandbox is not currently active.
 The part of the technology there that I'd really like to keep (in
some form) is the notion of continuations, but there's better ways to
do that than something that requires representing expressions in XML
syntax the way that [workflow] does right now.  For example, see
Cocoon Flow and Don Brown's adaptation of that to work inside Struts.


 sean

Craig

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

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang BooleanUtils.java

scolebourne2004/10/08 14:27:00

  Modified:lang/src/test/org/apache/commons/lang BooleanUtilsTest.java
   lang/src/java/org/apache/commons/lang BooleanUtils.java
  Log:
  Add isTrue and isFalse methods
  
  Revision  ChangesPath
  1.10  +14 -1 
jakarta-commons/lang/src/test/org/apache/commons/lang/BooleanUtilsTest.java
  
  Index: BooleanUtilsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/BooleanUtilsTest.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- BooleanUtilsTest.java 18 Feb 2004 23:06:19 -  1.9
  +++ BooleanUtilsTest.java 8 Oct 2004 21:27:00 -   1.10
  @@ -72,6 +72,19 @@
   }
   
   //---
  +public void test_isTrue_Boolean() {
  +assertEquals(true, BooleanUtils.isTrue(Boolean.TRUE));
  +assertEquals(false, BooleanUtils.isTrue(Boolean.FALSE));
  +assertEquals(false, BooleanUtils.isTrue((Boolean) null));
  +}
  +
  +public void test_isFalse_Boolean() {
  +assertEquals(false, BooleanUtils.isFalse(Boolean.TRUE));
  +assertEquals(true, BooleanUtils.isFalse(Boolean.FALSE));
  +assertEquals(false, BooleanUtils.isFalse((Boolean) null));
  +}
  +
  +//---
   public void test_toBooleanObject_boolean() {
   assertSame(Boolean.TRUE, BooleanUtils.toBooleanObject(true));
   assertSame(Boolean.FALSE, BooleanUtils.toBooleanObject(false));
  
  
  
  1.19  +41 -1 
jakarta-commons/lang/src/java/org/apache/commons/lang/BooleanUtils.java
  
  Index: BooleanUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/BooleanUtils.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- BooleanUtils.java 18 Feb 2004 22:59:50 -  1.18
  +++ BooleanUtils.java 8 Oct 2004 21:27:00 -   1.19
  @@ -68,6 +68,46 @@
   // boolean Boolean methods
   //---
   /**
  + * pIs a Boolean value codetrue/code, handling codenull/code./p
  + *
  + * pre
  + *   BooleanUtils.isTrue(Boolean.TRUE)  = true
  + *   BooleanUtils.isTrue(Boolean.FALSE) = false
  + *   BooleanUtils.isTrue(null)  = false
  + * /pre
  + *
  + * @param bool  the boolean to convert
  + * @return codetrue/code only if the input is non-null and true
  + * @since 2.1
  + */
  +public static boolean isTrue(Boolean bool) {
  +if (bool == null) {
  +return false;
  +}
  +return (bool.booleanValue() ? true : false);
  +}
  +
  +/**
  + * pIs a Boolean value codefalse/code, handling codenull/code./p
  + *
  + * pre
  + *   BooleanUtils.isFalse(Boolean.TRUE)  = false
  + *   BooleanUtils.isFalse(Boolean.FALSE) = true
  + *   BooleanUtils.isFalse(null)  = false
  + * /pre
  + *
  + * @param bool  the boolean to convert
  + * @return codetrue/code only if the input is non-null and false
  + * @since 2.1
  + */
  +public static boolean isFalse(Boolean bool) {
  +if (bool == null) {
  +return false;
  +}
  +return (bool.booleanValue() ? false : true);
  +}
  +
  +/**
* pBoolean factory that avoids creating new Boolean objecs all the time./p
* 
* pThis method was added to JDK1.4 but is available here for earlier 
JDKs./p
  
  
  

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

Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html MutableFloat.java MutableByte.java MutableShort.java MutableObject.java MutableLong.java MutableInt.java MutableDouble.java Mutable.java

2004-10-08 Thread Stephen Colebourne

There was rather a lot of automated reformatting in this commit ;-) Not sure
that is something I'd want to encourage in the future, unless the classes
existing format had issues.

Stephen

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 08, 2004 8:45 PM
Subject: cvs commit:
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html
MutableFloat.java MutableByte.java MutableShort.java MutableObject.java
MutableLong.java MutableInt.java MutableDouble.java Mutable.java




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

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable MutableFloat.java MutableObject.java

scolebourne2004/10/08 14:33:03

  Modified:lang/src/java/org/apache/commons/lang/mutable
MutableFloat.java MutableObject.java
  Log:
  Remove wrong Javadoc
  
  Revision  ChangesPath
  1.7   +1 -18 
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableFloat.java
  
  Index: MutableFloat.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableFloat.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- MutableFloat.java 8 Oct 2004 19:45:46 -   1.6
  +++ MutableFloat.java 8 Oct 2004 21:33:03 -   1.7
  @@ -163,7 +163,6 @@
* @param obj
*the object to be compared
* @return codetrue/code if the objects are the same; codefalse/code 
otherwise.
  - * @throws ClassCastException if the argument is not a MutableFloat
* @see java.lang.Float#floatToIntBits(float)
*/
   public boolean equals(Object obj) {
  @@ -172,22 +171,6 @@
   }
   
   //---
  -/**
  - * Checks if this object equals the specified object.
  - * p
  - * The object must be a MutableFloat with the same value to be equal.
  - * 
  - * @param obj
  - *the object to compare to
  - * @return true if equal
  - */
  -//public boolean equals(Object obj) {
  -//if (obj instanceof MutableFloat) {
  -//float other = ((MutableFloat) obj).value;
  -//return (Float.floatToIntBits(other) == 
Float.floatToIntBits(value));
  -//}
  -//return false;
  -//}
   /**
* Returns a suitable hashcode for this mutable.
* 
  
  
  
  1.4   +1 -2  
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableObject.java
  
  Index: MutableObject.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableObject.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- MutableObject.java8 Oct 2004 19:45:46 -   1.3
  +++ MutableObject.java8 Oct 2004 21:33:03 -   1.4
  @@ -79,7 +79,6 @@
* @param obj
*the object to compare with.
* @return codetrue/code if the objects are the same; codefalse/code 
otherwise.
  - * @throws ClassCastException if the argument is not a MutableObject
*/
   public boolean equals(Object obj) {
   if (obj instanceof MutableObject) {
  
  
  

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

cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang ValidateTest.java

scolebourne2004/10/08 14:44:41

  Modified:lang/src/java/org/apache/commons/lang Validate.java
   lang/src/test/org/apache/commons/lang ValidateTest.java
  Log:
  Rename allElementsOfClass to allElementsOfType, and change to instanceof check
  
  Revision  ChangesPath
  1.13  +19 -17
jakarta-commons/lang/src/java/org/apache/commons/lang/Validate.java
  
  Index: Validate.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/Validate.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Validate.java 1 Jun 2004 21:25:35 -   1.12
  +++ Validate.java 8 Oct 2004 21:44:41 -   1.13
  @@ -492,52 +492,54 @@
   }
   }
   }
  -
  +
   /**
* pValidate an argument, throwing codeIllegalArgumentException/code
* if the argument collection  is codenull/code or has elements that
  - * are not of type codeclazz/code./p
  + * are not of type codeclazz/code or a subclass./p
*
* pre
  - * Validate.allElementsOfClass(collection, String.class, Collection has 
invalid elements);
  + * Validate.allElementsOfType(collection, String.class, Collection has invalid 
elements);
* /pre
*
  - * @param collection  the collection to check
  - * @param clazz  the codeClass/code which the collection's elements are 
expected to be
  + * @param collection  the collection to check, not null
  + * @param clazz  the codeClass/code which the collection's elements are 
expected to be, not null
* @param message  the exception message if the codeCollection/code has 
elements not of type codeclazz/code
* @since 2.1
*/
  -public static void allElementsOfClass(Collection collection, Class clazz, 
String message) {
  +public static void allElementsOfType(Collection collection, Class clazz, String 
message) {
Validate.notNull(collection);
  +Validate.notNull(clazz);
for (Iterator it = collection.iterator(); it.hasNext(); ) {
  - if ((it.next().getClass().equals(clazz)) == false) {
  + if (clazz.isInstance(it.next()) == false) {
throw new IllegalArgumentException(message);
}
}
  -}   
  -
  +}
  +
   /**
* pValidate an argument, throwing codeIllegalArgumentException/code
* if the argument collection  is codenull/code or has elements that are 
not of 
  - * type codeclazz/code./p
  + * type codeclazz/code or a subclass./p
*
* pre
  - * Validate.allElementsOfClass(collection, String.class);
  + * Validate.allElementsOfType(collection, String.class);
* /pre
*
* pThe message in the exception is 'The validated collection contains an 
element not of type clazz at index: './p
* 
  - * @param collection  the collection to check
  - * @param clazz the codeClass/code which the collection's elements are 
expected to be
  + * @param collection  the collection to check, not null
  + * @param clazz the codeClass/code which the collection's elements are 
expected to be, not null
* @since 2.1
*/
  -public static void allElementsOfClass(Collection collection, Class clazz) {
  +public static void allElementsOfType(Collection collection, Class clazz) {
Validate.notNull(collection);
  +Validate.notNull(clazz);
int i = 0;
for (Iterator it = collection.iterator(); it.hasNext(); i++) {
  - if ((it.next().getClass().equals(clazz)) == false) {
  +if (clazz.isInstance(it.next()) == false) {
throw new IllegalArgumentException(The validated collection 
contains an element not of type 
  -+ (clazz == null ? null : clazz.getName()) +  at index:  + 
i);
  ++ clazz.getName() +  at index:  + i);
}
}
   }
  
  
  
  1.6   +23 -5 
jakarta-commons/lang/src/test/org/apache/commons/lang/ValidateTest.java
  
  Index: ValidateTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/ValidateTest.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- ValidateTest.java 18 Feb 2004 23:06:19 -  1.5
  +++ ValidateTest.java 8 Oct 2004 21:44:41 -   1.6
  @@ -358,23 +358,41 @@
   }
   
   //---
  -public void testAllElementsOfClass() {
  +public void testAllElementsOfType() {
List coll = new ArrayList();
coll.add(a);
coll.add(b);
  - Validate.allElementsOfClass(coll, String.class, MSG);
  + Validate.allElementsOfType(coll, String.class,

Re: cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html MutableFloat.java MutableByte.java MutableShort.java MutableObject.java MutableLong.java MutableInt.java MutableDouble.java Mutable.java

2004-10-08 Thread Mike Stanley

Tell Eclipse not to include javadoc comments in the format.  This is
what the majority of the diff contains (I recognize that crap ass
javadoc formating anywhere ;-) 

- Mike

On Fri, 2004-10-08 at 17:34, Stephen Colebourne wrote:

 There was rather a lot of automated reformatting in this commit ;-) Not sure
 that is something I'd want to encourage in the future, unless the classes
 existing format had issues.
 
 Stephen
 
 - Original Message -
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, October 08, 2004 8:45 PM
 Subject: cvs commit:
 jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.html
 MutableFloat.java MutableByte.java MutableShort.java MutableObject.java
 MutableLong.java MutableInt.java MutableDouble.java Mutable.java
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang WordUtilsTest.java

scolebourne2004/10/08 15:10:23

  Modified:lang/src/test/org/apache/commons/lang WordUtilsTest.java
  Log:
  Extra tests based on Javadoc
  
  Revision  ChangesPath
  1.8   +10 -1 
jakarta-commons/lang/src/test/org/apache/commons/lang/WordUtilsTest.java
  
  Index: WordUtilsTest.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/test/org/apache/commons/lang/WordUtilsTest.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- WordUtilsTest.java3 Jun 2004 03:49:47 -   1.7
  +++ WordUtilsTest.java8 Oct 2004 22:10:23 -   1.8
  @@ -184,6 +184,9 @@
   assertEquals(I Am+Here-123, WordUtils.capitalize(I Am+Here-123, chars) 
);
   assertEquals(I+Am-HERE 123, WordUtils.capitalize(i+am-HERE 123, chars) 
);
   assertEquals(I-AM HERE+123, WordUtils.capitalize(I-AM HERE+123, chars) 
);
  +chars = new char[] {'.'};
  +assertEquals(I aM.Fine, WordUtils.capitalize(i aM.fine, chars) );
  +assertEquals(I Am.fine, WordUtils.capitalize(i am.fine, null) );
   }
   
   public void testCapitalizeFully_String() {
  @@ -211,6 +214,9 @@
   assertEquals(I Am+Here-123, WordUtils.capitalizeFully(I Am+Here-123, 
chars) );
   assertEquals(I+Am-Here 123, WordUtils.capitalizeFully(i+am-HERE 123, 
chars) );
   assertEquals(I-Am Here+123, WordUtils.capitalizeFully(I-AM HERE+123, 
chars) );
  +chars = new char[] {'.'};
  +assertEquals(I am.Fine, WordUtils.capitalizeFully(i aM.fine, chars) );
  +assertEquals(I Am.fine, WordUtils.capitalizeFully(i am.fine, null) );
   }
   
   public void testUncapitalize_String() {
  @@ -238,6 +244,9 @@
   assertEquals(i+am here-123, WordUtils.uncapitalize(I+Am Here-123, 
chars) );
   assertEquals(i-am+hERE 123, WordUtils.uncapitalize(i-am+HERE 123, 
chars) );
   assertEquals(i aM-hERE+123, WordUtils.uncapitalize(I AM-HERE+123, 
chars) );
  +chars = new char[] {'.'};
  +assertEquals(i AM.fINE, WordUtils.uncapitalize(I AM.FINE, chars) );
  +assertEquals(i aM.FINE, WordUtils.uncapitalize(I AM.FINE, null) );
   }
   
   public void testSwapCase_String() {
  
  
  

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

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang WordUtils.java

scolebourne2004/10/08 15:10:37

  Modified:lang/src/java/org/apache/commons/lang WordUtils.java
  Log:
  Javadoc
  
  Revision  ChangesPath
  1.15  +19 -14
jakarta-commons/lang/src/java/org/apache/commons/lang/WordUtils.java
  
  Index: WordUtils.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/WordUtils.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- WordUtils.java2 Sep 2004 19:04:56 -   1.14
  +++ WordUtils.java8 Oct 2004 22:10:37 -   1.15
  @@ -255,13 +255,15 @@
* upper case./p
*
* pre
  - * WordUtils.capitalize(null)= null
  - * WordUtils.capitalize()  = 
  - * WordUtils.capitalize(i am FINE) = I Am FINE
  + * WordUtils.capitalize(null, *)= null
  + * WordUtils.capitalize(, *)  = 
  + * WordUtils.capitalize(*, new char[0]) = *
  + * WordUtils.capitalize(i am fine, null)  = I Am Fine
  + * WordUtils.capitalize(i aM.fine, {'.'}) = I aM.Fine
* /pre
* 
* @param str  the String to capitalize, may be null
  - * @param delimiters  set of characters to determine capitalization
  + * @param delimiters  set of characters to determine capitalization, null means 
whitespace
* @return capitalized String, codenull/code if null String input
* @see #uncapitalize(String)
* @see #capitalizeFully(String)
  @@ -342,14 +344,15 @@
* upper case./p
*
* pre
  - * WordUtils.capitalizeFully(null, null) = null
  - * WordUtils.capitalizeFully(, null)   = 
  - * WordUtils.capitalizeFully(i am FINE, new char[] {' '})  = I Am Fine
  - * WordUtils.capitalizeFully(i+am-FINE, new char[] {'-', '+'}) = I+Am-Fine
  + * WordUtils.capitalizeFully(null, *)= null
  + * WordUtils.capitalizeFully(, *)  = 
  + * WordUtils.capitalizeFully(*, null)= *
  + * WordUtils.capitalizeFully(*, new char[0]) = *
  + * WordUtils.capitalizeFully(i aM.fine, {'.'}) = I am.Fine
* /pre
* 
* @param str  the String to capitalize, may be null
  - * @param delimiters  set of characters to determine capitalization
  + * @param delimiters  set of characters to determine capitalization, null means 
whitespace
* @return capitalized String, codenull/code if null String input
*/
   public static String capitalizeFully(String str, char[] delimiters) {
  @@ -393,13 +396,15 @@
* A codenull/code input String returns codenull/code./p
*
* pre
  - * WordUtils.uncapitalize(null)= null
  - * WordUtils.uncapitalize()  = 
  - * WordUtils.uncapitalize(I Am FINE) = i am fINE
  + * WordUtils.uncapitalize(null, *)= null
  + * WordUtils.uncapitalize(, *)  = 
  + * WordUtils.uncapitalize(*, null)= *
  + * WordUtils.uncapitalize(*, new char[0]) = *
  + * WordUtils.uncapitalize(I AM.FINE, {'.'}) = i AM.fINE
* /pre
* 
* @param str  the String to uncapitalize, may be null
  - * @param delimiters  set of characters to determine uncapitalization
  + * @param delimiters  set of characters to determine uncapitalization, null 
means whitespace
* @return uncapitalized String, codenull/code if null String input
* @see #capitalize(String)
*/
  
  
  

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

cvs commit: jakarta-commons/lang/src/java/org/apache/commons/lang/mutable MutableObject.java

2004-10-08 Thread ggregory

ggregory2004/10/08 15:29:33

  Modified:lang/src/java/org/apache/commons/lang/mutable
MutableObject.java
  Log:
  Javadoc hashCode() more precisely.
  
  Revision  ChangesPath
  1.5   +4 -4  
jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableObject.java
  
  Index: MutableObject.java
  ===
  RCS file: 
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/mutable/MutableObject.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- MutableObject.java8 Oct 2004 21:33:03 -   1.4
  +++ MutableObject.java8 Oct 2004 22:29:33 -   1.5
  @@ -33,7 +33,7 @@
   private Object value;
   
   /**
  - * Constructs a new MutableObject with the default value of null.
  + * Constructs a new MutableObject with the default value of codenull/code.
*/
   public MutableObject() {
   super();
  @@ -89,9 +89,9 @@
   }
   
   /**
  - * Returns a suitable hashcode for this mutable.
  + * Returns the value's hash code or code0/code if the value is 
codenull/code.
* 
  - * @return a suitable hashcode
  + * @return the value's hash code or code0/code if the value is 
codenull/code.
*/
   public int hashCode() {
   return (value == null ? 0 : value.hashCode());
  
  
  

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

RE: cvs commit:jakarta-commons/lang/src/java/org/apache/commons/lang/mutable package.htmlMutableFloat.java MutableByte.java MutableShort.java MutableObject.javaMutableLong.java MutableInt.java MutableDouble.java Mutable.java

2004-10-08 Thread Gary Gregory

Ah... more fun stuff, my goal was the opposite than what you are
suggesting ;-) I suppose the policy should be don't change anything
unless you are fixing something, not sure.

In this case, I /wanted/ to format the Javadocs in order to have the
comments less like newspaper columns and make better use of the 120
chars width guideline we have. 

Gary

 -Original Message-
 From: Mike Stanley [mailto:[EMAIL PROTECTED]
 Sent: Friday, October 08, 2004 15:03
 To: Jakarta Commons Developers List
 Subject: Re: cvs commit:jakarta-
 commons/lang/src/java/org/apache/commons/lang/mutable
 package.htmlMutableFloat.java MutableByte.java MutableShort.java
 MutableObject.javaMutableLong.java MutableInt.java MutableDouble.java
 Mutable.java
 
 Tell Eclipse not to include javadoc comments in the format.  This is
 what the majority of the diff contains (I recognize that crap ass
 javadoc formating anywhere ;-)
 
 - Mike
 
 On Fri, 2004-10-08 at 17:34, Stephen Colebourne wrote:
 
  There was rather a lot of automated reformatting in this commit ;-)
Not
 sure
  that is something I'd want to encourage in the future, unless the
 classes
  existing format had issues.
 
  Stephen
 
  - Original Message -
  From: [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Sent: Friday, October 08, 2004 8:45 PM
  Subject: cvs commit:
  jakarta-commons/lang/src/java/org/apache/commons/lang/mutable
 package.html
  MutableFloat.java MutableByte.java MutableShort.java
MutableObject.java
  MutableLong.java MutableInt.java MutableDouble.java Mutable.java
 
 
 
 
 
-
  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]

cvs commit: jakarta-commons/cli/src/java/org/apache/commons/cli2/option DefaultOption.java Switch.java Command.java