DO NOT REPLY [Bug 33872] - API Javadoc not in sync with jar nor with source code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33872


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-07 08:48 ---
Thanks for comment.
It is somehow confusing that in the middle of the first page, API doc points to
something that's not yet released. 
After reading your comment I saw two javadoc links on the left.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33872] - API Javadoc not in sync with jar nor with source code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33872





--- Additional Comments From [EMAIL PROTECTED]  2005-03-07 08:33 ---
>From the download pages you can access the latest release of [configuration],
which is 1.0. At the moment we are preparing release 1.1, the current version is
release candidate 1.1RC2, which came out yesterday. The setPath() method you
mentioned did not exist in version 1.0.

>From the configuration main site we link to different javadocs: To the latest
version (which is the unreleased 1.1RC2) and to version 1.0. So you have to
ensure that you use the correct link, which corresponds to your version of
configuration.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [lang]/[servlet] Doing some tickling

[Henri Yandell]

On Sun, 06 Mar 2005 23:22:57 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Thanks for the comments Henri!  I did see those comments.  Rather than
> reply on the ticket, I thought here might be more appropriate.
> 
> I don't think I can really comment on the idea of it being a tiny bit of
> something larger.  You may be 100% right, and this functionality would
> be rolled into that, but I do think this comes up for people enough that
> it might be nice to have sooner rather than later, even if with the
> understanding that down the road it will be expanded greatly.

Largely trying to avoid throwing it straight in as after many moons of
failing, I'm making a push to get 2.1 out :)

On the larger ideas (DateRange class), I'd imagine an API of:

// DateRange might not extend the math.Range, but would mimic the API
DateRange range = new DateRange(date1, date2, Calendar.HOUR);
if(range.contains(new Date())) { .. }

Unsure. Maybe it'd be simpler with TimeRange being another range that
provides the kind of feature you want, ie) only based on the time of
day. That way the rather dodgy Calendar.HOUR bit can be thrown out.

> I did find your concern about ints interesting though, and I wanted to
> explain my rationale for that... Very simply, I think the most common
> usage of this type of function will result from wanting to know if a
> given Calendar object's time falls within a given range.  Since the
> Calendar's get method returns an int, it seems logical to me.  In
> addition, I think a simple (relatively simple anyway) comparison of ints
> is the easiest way to accomplish this function.  I would be interested
> to know how you would envision it being done with something other than ints.

Given the criteria above, at least an API of: 

DateUtils.inRange(Date time, int startHours, int startMinutes, int
endHours, int endMinutes)

It's the 2,358 number I dislike :)

We tend to make the target the first parameter btw, but that's no
biggy. I also switched it to be a Date.

Another approach would be if we added a Time class to represent a time
value independent of the day. I'm not sure if Stephen did this in
JODA, but I suspect that it would be a simple enough addition. Maybe
we could extend java.util.Date so that it could still be used easily
in DateFormat/JDBC etc. Some issues with that, but might be usable
enough with them.

The String variants have the p/pm hardcoded, which will be a bit
limiting. It'd make things slower, but I presume you could use a
SimpleDateFormat here.

> On the servlet thing... I originally mentioned these additions probably
> three months ago.  The same thing basically was said about the status of
> the project as what you said.  It was mentioned (I forget by who
> frankly) that submitting these could be the impetuous for getting a
> first release out the door.  That might be a little too hopeful frankly,
> but it couldn't hurt, as you kind of say :)

Might even have been me that said it :(

Will take a look tomorrow.

Hen

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

svn commit: r156403 - jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java

[skitching]

Author: skitching
Date: Sun Mar  6 23:21:13 2005
New Revision: 156403

URL: http://svn.apache.org/viewcvs?view=rev&rev=156403
Log:
Provide ability to pass special NO_DEFAULT object as the "defaultValue"
parameter to the constructor. Also fix misleading javadoc.

Modified:

jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java?view=diff&r1=156402&r2=156403
==
--- 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
 Sun Mar  6 23:21:13 2005
@@ -72,11 +72,25 @@
  */
 public AbstractArrayConverter(Object defaultValue) {
 
-this.defaultValue = defaultValue;
-this.useDefault = true;
+if (defaultValue == NO_DEFAULT) {
+this.useDefault = false;
+} else {
+this.defaultValue = defaultValue;
+this.useDefault = true;
+}
 
 }
 
+// --- Static Variables
+
+/**
+ * This is a special reference that can be passed as the "default object"
+ * to the constructor to indicate that no default is desired. Note that
+ * the value 'null' cannot be used for this purpose, as the caller may
+ * want a null to be returned as the default.
+ */
+public static final Object NO_DEFAULT = new Object();
+
 // - Instance Variables
 
 
@@ -123,11 +137,12 @@
  * in the Java language into a List individual Strings
  * for each element, according to the following rules.
  * 
- * The string must have matching '{' and '}' delimiters around
- * a comma-delimited list of values.
- * Whitespace before and after each element is stripped.
- * If an element is itself delimited by matching single or double
- * quotes, the usual rules for interpreting a quoted String apply.
+ * The string is expected to be a comma-separated list of values.
+ * The string may optionally have matching '{' and '}' delimiters
+ *   around the list.
+ * Whitespace before and after each element is stripped.
+ * Elements in the list may be delimited by single or double quotes.
+ *  Within a quoted elements, the normal Java escape sequences are 
valid.
  * 
  *
  * @param svalue String value to be parsed



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

svn commit: r156402 - jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/Converter.java

[skitching]

Author: skitching
Date: Sun Mar  6 23:18:54 2005
New Revision: 156402

URL: http://svn.apache.org/viewcvs?view=rev&rev=156402
Log:
Updated javadoc to note thread-safety requirement for Converter subclasses.

Modified:

jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/Converter.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/Converter.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/Converter.java?view=diff&r1=156401&r2=156402
==
--- 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/Converter.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/Converter.java
 Sun Mar  6 23:18:54 2005
@@ -21,7 +21,15 @@
 /**
  * General purpose data type converter that can be registered and used
  * within the BeanUtils package to manage the conversion of objects from
- * one type to another.
+ * one type to another.
+ *
+ * Converter subclasses bundled with the BeanUtils library are required
+ * to be thread-safe, as users of the library may call conversion methods
+ * from more than one thread simultaneously.
+ *
+ * Custom converter subclasses created by users of the library can be
+ * non-thread-safe if the application using them is single-threaded. However
+ * it is recommended that they be written in a thread-safe manner anyway. 
  *
  * @author Craig McClanahan
  * @author Paulo Gaspar



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

DO NOT REPLY [Bug 33872] New: - API Javadoc not in sync with jar nor with source code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33872

   Summary: API Javadoc not in sync with jar nor with source code
   Product: Commons
   Version: unspecified
  Platform: All
   URL: http://jakarta.apache.org/commons/configuration/apidocs/
org/apache/commons/configuration/AbstractFileConfigurati
on.html#setPath(java.lang.String)
OS/Version: All
Status: NEW
  Severity: minor
  Priority: P4
 Component: Configuration
AssignedTo: commons-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


At least setPath method of AbstrastFileConfiguration exists neither in bin, nor
ins src versions i found on
http://jakarta.apache.org/commons/configuration/downloads.html

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [lang] 2.1 rc (practice)

[Henri Yandell]

On Sun, 06 Mar 2005 21:42:30 -0500, Phil Steitz <[EMAIL PROTECTED]> wrote:
> Henri Yandell wrote:
> > It's done on a Mac under 1.4, so I need to get a Linux 1.2 going for
> > the real thing, but I've created a distribution for 2.1:
> >
> > http://www.apache.org/~bayard/commons-lang-2.1/
> >
> A couple of things to look at / fix:
> 
> 1) Both src and binaries are missing NOTICE.txt

So is the .jar file, which should probably have it too (to go with the
LICENSE.txt).

> 2) ant clean test using source distro fails here:
> 
> 
>  
>  
>  
>  
>  
> 
> due to ${conf.home} undefined.

Nice. Looks like the default.properties doesn't get put into the build.

> 3) the binary dist is fat. The 2.0 binary tarball was under 500k and the
> 2.1 candidate is over 2MB.  This is all due to the site stuff.  Might be
> better to turn off some / most of the maven project reports (esp. the
> xref reports) and drop some of the maven image / logo cruft.  For the
> latter, have a look at the maven.xml for directory-naming.  Could be
> this (ability to prevent unused images/logos from being copied out) is
> now available in the latest maven xdoc plugin.

Nasty. 

I'm -0 to the whole placing of the site in the dists. Seems like a
waste of bandwidth.

Documentation should be in there, but a site != documentation (maven's
fault, though other non-maven places do exactly the same thing) and
much of the documentation is hardly pertinent (source xref's?). I can
see some argument for it being in th src dists, but we don't even have
it there. Is there anything other than javadoc that should be there?
The userguide is the only thing that jumps to mind, but it's
incomplete.

Only -0 because I'll never have to download the dists. I'll be using
the ibiblio .jar file and the online javadoc (until they get
overwritten by the latest from HEAD, which is a well known grumble for
another time).

Hen

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

svn commit: r156391 - in jakarta/commons/sandbox/benchmark/trunk: ./ src/java/org/apache/commons/benchmark/ src/java/org/apache/commons/benchmark/xmlrpc/ src/test/org/apache/commons/benchmark/ xdocs/

[burton]

Author: burton
Date: Sun Mar  6 20:44:38 2005
New Revision: 156391

URL: http://svn.apache.org/viewcvs?view=rev&rev=156391
Log:
refactored to store individual metadata into a class

Added:

jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/BenchmarkMeta.java
Modified:
jakarta/commons/sandbox/benchmark/trunk/project.xml

jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java

jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/BenchmarkTracker.java

jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/xmlrpc/BenchmarkHandler.java

jakarta/commons/sandbox/benchmark/trunk/src/test/org/apache/commons/benchmark/Test1.java
jakarta/commons/sandbox/benchmark/trunk/xdocs/index.xml

Modified: jakarta/commons/sandbox/benchmark/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/project.xml?view=diff&r1=156390&r2=156391
==
--- jakarta/commons/sandbox/benchmark/trunk/project.xml (original)
+++ jakarta/commons/sandbox/benchmark/trunk/project.xml Sun Mar  6 20:44:38 2005
@@ -15,7 +15,7 @@
 
 Jakarta Benchmark
 
-0.0.2
+0.0.3
 
 org.apache.commons.benchmark
 
@@ -55,6 +55,13 @@
 
 
 
+
+
+commons-beanutils
+1.7.0
+
+
+jrobin1.4.0
 
 
 xml-apis2.0.2

Modified: 
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java?view=diff&r1=156390&r2=156391
==
--- 
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
 (original)
+++ 
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/Benchmark.java
 Sun Mar  6 20:44:38 2005
@@ -144,22 +144,6 @@
 //  metadata about this benchmark 
***
 
 /**
- * The total number of start()ed benchmarks since in the last rollover.
- * @deprecated
- */
-public long getTotalStarted() {
-return tracker1.lastStarted;
-}
-
-/**
- * The total number of complete()ed benchmarks since in the last rollover.
- * @deprecated
- */
-public long getTotalCompleted() {
-return tracker1.lastCompleted;
-}
-
-/**
  * Get the tracker for this benchmark which includes all metadata related 
to
  * this benchmark including total completed/started and current values.
  *
@@ -313,63 +297,23 @@
 return "1min: " +
 "now=("  +
 "started:" +
-getTracker1().getStarted() +
+getTracker1().now.getStarted() +
 "," +
 "completed:" +
-getTracker1().getCompleted() +
+getTracker1().now.getCompleted() +
 "," +
 "duration:" +
-getTracker1().getDuration() +
+getTracker1().now.getDuration() +
 ")" + 
 " " +
 "last=("  +
 "started:" +
-getTracker1().getLastStarted() +
+getTracker1().last.getStarted() +
 "," +
 "completed:" +
-getTracker1().getLastCompleted() +
+getTracker1().last.getCompleted() +
 ")";
 
-}
-
-//  test code 
***
-
-/**
- * Quick benchmark code testing.
- */
-public static void main( String[] args ) throws Exception {
-
-//FIXME: we should also support benchmarking of code regions and 
whether
-//we're IN a code region.  That would be interesting to.  Have a bunch
-//of start() complete() methods and then I could benchmark how many are
-//open at a given time.
-//
-// This would support total number of completed operations and total
-// number of pending operations within a given timeframe.
-
-//simple testing framework
-
-INTERVAL_1 = 10 * 1000;
-
-Benchmark benchmark = getBenchmark( Benchmark.class );
-benchmark = benchmark.child( "main" );
-
-System.out.println( "name: " + benchmark.getName() );
-
-for ( int i = 0; i < 60; ++i ) {
-
-benchmark.start();
-
-//do something slow...
-Thread.sleep( INTERVAL_1 + 10 );
-
-benchmark.complete();
-
-System.out.println( "started: " + benchmark.getTotalStarted() );
-System.out.println( "completed: " + benchmark.getTotalCompleted() 
);
-
-}
-
 }
 
 }

Added: 
jakarta/commons/sandbox/benchmark/trunk/src/java/org/apache/commons/benchmark/BenchmarkMeta.

Re: [lang] 2.1 rc (practice)

[Phil Steitz]

Henri Yandell wrote:
It's done on a Mac under 1.4, so I need to get a Linux 1.2 going for
the real thing, but I've created a distribution for 2.1:
http://www.apache.org/~bayard/commons-lang-2.1/
A couple of things to look at / fix:
1) Both src and binaries are missing NOTICE.txt
2) ant clean test using source distro fails here:







due to ${conf.home} undefined.
3) the binary dist is fat. The 2.0 binary tarball was under 500k and the 
2.1 candidate is over 2MB.  This is all due to the site stuff.  Might be 
better to turn off some / most of the maven project reports (esp. the 
xref reports) and drop some of the maven image / logo cruft.  For the 
latter, have a look at the maven.xml for directory-naming.  Could be 
this (ability to prevent unused images/logos from being copied out) is 
now available in the latest maven xdoc plugin.

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

Re: [lang]/[servlet] Doing some tickling

[Frank W. Zammetti]

Thanks for the comments Henri!  I did see those comments.  Rather than 
reply on the ticket, I thought here might be more appropriate.

I don't think I can really comment on the idea of it being a tiny bit of 
something larger.  You may be 100% right, and this functionality would 
be rolled into that, but I do think this comes up for people enough that 
it might be nice to have sooner rather than later, even if with the 
understanding that down the road it will be expanded greatly.

I did find your concern about ints interesting though, and I wanted to 
explain my rationale for that... Very simply, I think the most common 
usage of this type of function will result from wanting to know if a 
given Calendar object's time falls within a given range.  Since the 
Calendar's get method returns an int, it seems logical to me.  In 
addition, I think a simple (relatively simple anyway) comparison of ints 
is the easiest way to accomplish this function.  I would be interested 
to know how you would envision it being done with something other than ints.

On the servlet thing... I originally mentioned these additions probably 
three months ago.  The same thing basically was said about the status of 
the project as what you said.  It was mentioned (I forget by who 
frankly) that submitting these could be the impetuous for getting a 
first release out the door.  That might be a little too hopeful frankly, 
but it couldn't hurt, as you kind of say :)

Thanks again for taking the time to look and comment!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Henri Yandell wrote:
Commented on the DateUtils one a bit earlier.
On 33825, my view is that it's a tiny bit of something larger
(DateRange) and that we should get it in the planning for 3.0, but
that there's more than enough discussion to go on to try and get it
into 2.1.
On the servlet one, I'll take a look. [servlet]'s status is as a vague
collection of methods, slowly collecting to be worthy of release, so
anything's worth adding I reckon.
Hen
On Sun, 06 Mar 2005 11:39:23 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
Hope everyone is having a good weekend!
I just wanted to drop a line and kind of tickle some devs on two tickets
I had opened:
[lang] 33825 - New methods for DateUtils
[servlet] 33676 - SessionUtils and new methods for RequestUtils
Just curious to see if anyone had looked at them (there are no comments
posted on them, but that doesn't necessarily indicate no one has looked
at them).  Thanks!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.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]

DO NOT REPLY [Bug 33377] - [jxpath] asPath() returns a path to the last sibling

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33377


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-07 04:50 ---
Fixed the problem by cloning the pointer in NodePointer.getImmediateValuePointer
().

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r156386 - jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/PropertyPointer.java

[dmitri]

Author: dmitri
Date: Sun Mar  6 19:50:06 2005
New Revision: 156386

URL: http://svn.apache.org/viewcvs?view=rev&rev=156386
Log:
Fixed bug 33377. See http://issues.apache.org/bugzilla/show_bug.cgi?id=33377

Modified:

jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/PropertyPointer.java

Modified: 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/PropertyPointer.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/PropertyPointer.java?view=diff&r1=156385&r2=156386
==
--- 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/PropertyPointer.java
 (original)
+++ 
jakarta/commons/proper/jxpath/trunk/src/java/org/apache/commons/jxpath/ri/model/beans/PropertyPointer.java
 Sun Mar  6 19:50:06 2005
@@ -125,7 +125,7 @@
  */
 public NodePointer getImmediateValuePointer() {
 return NodePointer.newChildNodePointer(
-this,
+(NodePointer) this.clone(),
 getName(),
 getImmediateNode());
 }



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

svn commit: r156383 - jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java

[skitching]

Author: skitching
Date: Sun Mar  6 19:26:56 2005
New Revision: 156383

URL: http://svn.apache.org/viewcvs?view=rev&rev=156383
Log:
Code tidyups without any functionality change:
 * Added constructors; it is cleaner for an abstract class
   to initialise its own members than require its subclasses
   to initialise them.
 * Made protected strings member final. Theoretically this is
   a "breaking API change". However only a complete nutter would
   ever write a class that would modify this member; the results
   would be very odd!

Modified:

jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java?view=diff&r1=156382&r2=156383
==
--- 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/java/org/apache/commons/beanutils/converters/AbstractArrayConverter.java
 Sun Mar  6 19:26:56 2005
@@ -50,19 +50,46 @@
 public abstract class AbstractArrayConverter implements Converter {
 
 
-// - Instance Variables
+// --- Constructors
 
 
 /**
- * The default value specified to our Constructor, if any.
+ * Create a [EMAIL PROTECTED] Converter} that will throw a [EMAIL 
PROTECTED] ConversionException}
+ * if a conversion error occurs.
  */
-protected Object defaultValue = null;
+public AbstractArrayConverter() {
+
+this.defaultValue = null;
+this.useDefault = false;
+
+}
+
+/**
+ * Create a [EMAIL PROTECTED] Converter} that will return the specified 
default value
+ * if a conversion error occurs.
+ *
+ * @param defaultValue The default value to be returned
+ */
+public AbstractArrayConverter(Object defaultValue) {
+
+this.defaultValue = defaultValue;
+this.useDefault = true;
+
+}
+
+// - Instance Variables
 
 
 /**
  * Model object for string arrays.
  */
-protected static String strings[] = new String[0];
+protected static final String strings[] = new String[0];
+
+
+/**
+ * The default value specified to our Constructor, if any.
+ */
+protected Object defaultValue = null;
 
 
 /**



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

Re: [lang]/[servlet] Doing some tickling

[Henri Yandell]

Commented on the DateUtils one a bit earlier.

On 33825, my view is that it's a tiny bit of something larger
(DateRange) and that we should get it in the planning for 3.0, but
that there's more than enough discussion to go on to try and get it
into 2.1.

On the servlet one, I'll take a look. [servlet]'s status is as a vague
collection of methods, slowly collecting to be worthy of release, so
anything's worth adding I reckon.

Hen

On Sun, 06 Mar 2005 11:39:23 -0500, Frank W. Zammetti
<[EMAIL PROTECTED]> wrote:
> Hope everyone is having a good weekend!
> 
> I just wanted to drop a line and kind of tickle some devs on two tickets
> I had opened:
> 
> [lang] 33825 - New methods for DateUtils
> [servlet] 33676 - SessionUtils and new methods for RequestUtils
> 
> Just curious to see if anyone had looked at them (there are no comments
> posted on them, but that doesn't necessarily indicate no one has looked
> at them).  Thanks!
> 
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.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]

[lang] 2.1 rc (practice)

[Henri Yandell]

It's done on a Mac under 1.4, so I need to get a Linux 1.2 going for
the real thing, but I've created a distribution for 2.1:

http://www.apache.org/~bayard/commons-lang-2.1/

As far as remaining 2.1 issues, we only really have the request for
DateUtils.iterator's javadoc to be better.

Using JDiff, the only API differences would appear to be the removal
of  toString(Object, ToStringStyle, boolean, Class); String from
ReflectionToStringBuilder.

Other than that, the 1.2 build and any javadoc improvements which
might be thrown in, I can't see any reason not to go for the release
now.

Sorry I've been so slow,

Hen

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

Re: [id] Getting out of the sanbox...

[Phil Steitz]

I just committed what I think is a fix for this:

I was not able to get John's patch, but hopefully the changes I 
committed capture the spirit. I changed the load method in the State 
interface to throw Exception rather than IllegalStateException.  The 
rationale for this change is that all kinds of exceptions could be 
thrown in different load impls (including parse exceptions in the xml 
file-based ReadOnlyResourceStateImpl.load, which were being wrapped in 
IllegalStateExceptions).  If there are any objections to the changes, I 
will roll them back, but we need to address the NPE and exception 
swallowing in any case.

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

svn commit: r156371 - in jakarta/commons/sandbox/id/trunk/src: java/org/apache/commons/id/uuid/NodeManagerImpl.java java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java java/org/apache/commons/id/uuid/state/State.java test/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImplTest.java

[psteitz]

Author: psteitz
Date: Sun Mar  6 18:45:35 2005
New Revision: 156371

URL: http://svn.apache.org/viewcvs?view=rev&rev=156371
Log:
Improved exception management.
Stopped wrapping all throwables in IllegalStateExceptions in 
ReadOnlyResourceStateImpl.load.
Changed load in State interface to throw Exception instead of 
IllegalStateException (so other kinds of exceptions can be
propagated).
Eliminated NPE in finally block of ReadOnlyResourceStateImpl.load.
Reported by: John.E.Gregg 

Modified:

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/NodeManagerImpl.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java

jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/State.java

jakarta/commons/sandbox/id/trunk/src/test/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImplTest.java

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/NodeManagerImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/NodeManagerImpl.java?view=diff&r1=156370&r2=156371
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/NodeManagerImpl.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/NodeManagerImpl.java
 Sun Mar  6 18:45:35 2005
@@ -57,7 +57,11 @@
 /** Initialization */
 public void init() {
 nodeState = StateHelper.getStateImpl();
-nodeState.load();
+try {
+nodeState.load();
+} catch (Exception ex) {
+  throw new RuntimeException(ex);
+}
 nodesSet = nodeState.getNodes();
 Iterator it = nodesSet.iterator();
 allNodes = new Node[nodesSet.size()];

Modified: 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java?view=diff&r1=156370&r2=156371
==
--- 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java
 (original)
+++ 
jakarta/commons/sandbox/id/trunk/src/java/org/apache/commons/id/uuid/state/ReadOnlyResourceStateImpl.java
 Sun Mar  6 18:45:35 2005
@@ -84,13 +84,20 @@
  * See the documentation for further information on configuration
  * tasks.
  *
+ * @throws IllegalStateException if the 
"commons.uuid.configFileName"
+ * system property is not set or the resource cannot be loaded.
+ * @throws SAXException if an xml parsing error occurs
+ * @throws ParserConfigurationException if the parser cannot be loaded
+ * @throws IOException if an error occurs reading the file
+ * 
  * @see org.apache.commons.id.uuid.state.State#load()
  */
-public void load() throws IllegalStateException {
+public void load() throws Exception {
 // Get the resource name
 String resourceName = System.getProperty(CONFIG_FILENAME_KEY);
 if (resourceName == null) {
-throw new IllegalStateException("No value set for system property: 
" + CONFIG_FILENAME_KEY);
+throw new IllegalStateException("No value set for system property: 
" 
++ CONFIG_FILENAME_KEY);
 }
 
 // Load the resource
@@ -98,18 +105,18 @@
 try {
 in = ClassLoader.getSystemResourceAsStream(resourceName);
 if (in == null) {
-throw new IllegalStateException(resourceName + " loaded as 
system resource is null");
+throw new IllegalStateException(resourceName + 
+" loaded as system resource is null");
 }
-
 //Do the XML parsing
 parse(in);
-} catch (Throwable e) {
-throw new IllegalStateException(e.getMessage());
 } finally {
-try {
-in.close();
-} catch (IOException ioe) {
-//Nothing to do at this point.
+if (in != null) {
+try {
+in.close();
+} catch (IOException ioe) {
+//Nothing to do at this point.
+}
 }
 }
 }
@@ -151,17 +158,14 @@
  *
  * @param in the XML input stream to parse.
  */
-protected void parse(InputStream in) {
+protected void parse(InputStream in) throws Exception {
 DefaultHandler handler = new StateConfigHandler();
 SAXParserFactory saxFactory = SAXParserFactory.newInstance();
 saxFactory.setValidating(true);
-try {
-SAXParser parser = saxFactory.newSAXParser();
-parser.parse(in, handler);
-} cat

svn commit: r156365 - jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java

[skitching]

Author: skitching
Date: Sun Mar  6 18:21:12 2005
New Revision: 156365

URL: http://svn.apache.org/viewcvs?view=rev&rev=156365
Log:
Added dummy test method to keep junit happy; a TestCase class
without any test methods is reported as an error.

Modified:

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java?view=diff&r1=156364&r2=156365
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/converters/BaseLocaleConverterTestCase.java
 Sun Mar  6 18:21:12 2005
@@ -22,7 +22,9 @@
 import org.apache.commons.beanutils.locale.BaseLocaleConverter;
 
 /**
- * Base Test Case for the DecimalLocaleConverter classes.
+ * Base Test Case for the DecimalLocaleConverter classes. This class doesn't
+ * define any real tests; it just provides useful methods for the real
+ * test case classes to inherit.
  *
  * @author Niall Pemberton
  * @version $Revision$ $Date$
@@ -252,5 +254,13 @@
 
 }
 
+/**
+ * This class isn't intended to perform any real tests; it just provides
+ * methods for the real test cases to inherit. However junit complains
+ * if a class named ..TestCase contains no test methods, so here we
+ * define a dummy one to keep it happy.
+ */
+public void testNothing() {
+}
 }
 



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

svn commit: r156362 - jakarta/commons/proper/beanutils/trunk/project.xml

[skitching]

Author: skitching
Date: Sun Mar  6 18:18:27 2005
New Revision: 156362

URL: http://svn.apache.org/viewcvs?view=rev&rev=156362
Log:
Add dependency on junit, so maven builds work.
Also added myself to developer list.

Modified:
jakarta/commons/proper/beanutils/trunk/project.xml

Modified: jakarta/commons/proper/beanutils/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/project.xml?view=diff&r1=156361&r2=156362
==
--- jakarta/commons/proper/beanutils/trunk/project.xml (original)
+++ jakarta/commons/proper/beanutils/trunk/project.xml Sun Mar  6 18:18:27 2005
@@ -128,6 +128,12 @@
   niallp at apache dot org
   Apache Software Foundation
 
+
+  Simon Kitching
+  skitching
+  [EMAIL PROTECTED]
+  Apache Software Foundation
+
   
 
   
@@ -149,6 +155,10 @@
 
   commons-logging
   1.0.3
+
+
+  junit
+  3.8.1
 
   
 



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

svn commit: r156359 - in jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils: BeanificationTestCase.java locale/LocaleBeanificationTestCase.java

[skitching]

Author: skitching
Date: Sun Mar  6 18:12:01 2005
New Revision: 156359

URL: http://svn.apache.org/viewcvs?view=rev&rev=156359
Log:
Make test work correctly when run as "maven test". It would appear
that this causes junit tests to run in a custom classloader which
didn't work with the previous code.

Modified:

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanificationTestCase.java

jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanificationTestCase.java

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanificationTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanificationTestCase.java?view=diff&r1=156358&r2=156359
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanificationTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/BeanificationTestCase.java
 Sun Mar  6 18:12:01 2005
@@ -96,7 +96,7 @@
 public void testMemoryTestMethodology() throws Exception {
 // test methodology
 // many thanks to Juozas Baliuka for suggesting this method
-ClassLoader loader = new ClassLoader() {};
+ClassLoader loader = new ClassLoader(this.getClass().getClassLoader()) 
{};
 WeakReference reference = new  WeakReference(loader);
 Class myClass = 
loader.loadClass("org.apache.commons.beanutils.BetaBean");
 

Modified: 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanificationTestCase.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanificationTestCase.java?view=diff&r1=156358&r2=156359
==
--- 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanificationTestCase.java
 (original)
+++ 
jakarta/commons/proper/beanutils/trunk/src/test/org/apache/commons/beanutils/locale/LocaleBeanificationTestCase.java
 Sun Mar  6 18:12:01 2005
@@ -100,7 +100,7 @@
 public void testMemoryTestMethodology() throws Exception {
 // test methodology
 // many thanks to Juozas Baliuka for suggesting this method
-ClassLoader loader = new ClassLoader() {};
+ClassLoader loader = new ClassLoader(this.getClass().getClassLoader()) 
{};
 WeakReference reference = new  WeakReference(loader);
 Class myClass = 
loader.loadClass("org.apache.commons.beanutils.BetaBean");
 



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

DO NOT REPLY [Bug 33550] - [digester] Add support for CallMethodRule with target offset in xml rules

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33550





--- Additional Comments From [EMAIL PROTECTED]  2005-03-07 00:26 ---

Not at all; I'm just glad to see it fixed and closed.

BTW, earlier you asked:
> Is this thing about having a string containing a comma-separated 
> list of types an established xmlrules convention, 

and I wanted to note that not only does Digester/xmlrules use comma-separated
lists, but it also shows up in Ant:
   http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[ANNOUNCEMENT] Jakarta Commons Logging 1.0.5 Alpha1 Released

[robert burrell donkin]

Jakarta Commons Logging is a thin bridging logging API. For more
information on JCL see http://jakarta.apache.org/commons/logging/.

This release adds optional improved memory recycling for modern JVMs.
This is particular important for hot deployment in containers which do
not explicitly support JCL memory management.

This alpha release has been created to allow testing of this new code by
the wider user community. If you use JCL please download this release
and test it. Please report any problems to the commons-dev mailing list
or record them in bugzilla.

This release can be downloaded from
http://cvs.apache.org/dist/jakarta/commons/logging/. 

Robert


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

DO NOT REPLY [Bug 33550] - [digester] Add support for CallMethodRule with target offset in xml rules

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33550


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 23:47 ---
Thanks very much Wendy. Your code has been committed, with some minor changes. 
The (simple) changes make the test more obvious, though sadly a little less
interesting :-). I hope you don't mind. 


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r156347 - in jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules: CallParamTestObject.java DigesterLoaderRulesTest.java

[skitching]

Author: skitching
Date: Sun Mar  6 14:42:30 2005
New Revision: 156347

URL: http://svn.apache.org/viewcvs?view=rev&rev=156347
Log:
Added tests for the "target offset" feature of CallMethodRule.
Patch provided by Wendy Smoak.

Modified:

jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/CallParamTestObject.java

jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderRulesTest.java

Modified: 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/CallParamTestObject.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/CallParamTestObject.java?view=diff&r1=156346&r2=156347
==
--- 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/CallParamTestObject.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/CallParamTestObject.java
 Sun Mar  6 14:42:30 2005
@@ -53,8 +53,17 @@
 return middle;
 }
 
-
-
+public void setLeft(String left) {
+this.left=left;
+}
+
+public void setRight(String right) {
+this.right = right;
+}
+
+public void setMiddle(String middle) {
+this.middle = middle;
+}
 
 public String toString() {
 return "LEFT: " + left + " MIDDLE:" + middle + " RIGHT:" + right;

Modified: 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderRulesTest.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderRulesTest.java?view=diff&r1=156346&r2=156347
==
--- 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderRulesTest.java
 (original)
+++ 
jakarta/commons/proper/digester/trunk/src/test/org/apache/commons/digester/xmlrules/DigesterLoaderRulesTest.java
 Sun Mar  6 14:42:30 2005
@@ -72,6 +72,61 @@
 digester.parse(new InputSource(new StringReader(xml)));
 assertEquals("First param", "", testObject.getLeft());
 assertEquals("Param with default set", "tester.test", 
testObject.getRight());
+}
+
+/** Test for call method rule with target offset */
+public void testCallMethodRuleTargetOffset() throws Exception {
+String xmlRules = 
+"" +
+"" + 
+"  " +
+" " +
+"" +
+"" +
+" " +
+" " +
+"" +
+"" +
+" " +
+" " +
+"" +
+"" +
+" " +
+"   " +
+"";
 
+String xml = 
+"" + 
+"" +
+"  DataForTheTopObject" +
+"  
DataForTheParentObject" +
+"  DataForTheRootObject" +
+"";
+
+CallParamTestObject testObjectA = new CallParamTestObject();
+CallParamTestObject testObjectB = new CallParamTestObject();
+CallParamTestObject testObjectC = new CallParamTestObject();
+Digester digester = DigesterLoader.createDigester(new InputSource(new 
StringReader(xmlRules)));
+digester.push( testObjectA );
+digester.push( testObjectB );
+digester.push( testObjectC );
+digester.parse(new InputSource(new StringReader(xml)));
+
+assertEquals("Top object invoked", "DataForTheTopObject", 
testObjectC.getMiddle());
+assertEquals("Parent object invoked", "DataForTheParentObject", 
testObjectB.getLeft());
+assertEquals("Root object invoked", "DataForTheRootObject", 
testObjectA.getRight());
+
 }
 }



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

DO NOT REPLY [Bug 33840] - [BeanUtils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33840


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 21:32 ---
After looking at this problem, it stemmed from the fact that
PropertyUtils.isReadable() had a looser criteria for determining if a method was
readable than PropertyUtils.getProperty().  The patch brings isReadable() in
line with getProperty(), which I think makes for a cleaner solution than
throwing new exceptions in getProperty().

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33840] - [BeanUtils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33840





--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 21:29 ---
Created an attachment (id=14417)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14417&action=view)
changed isReadable() to use MethodUtis.getAccessibleMethod()


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33840] - [BeanUtils] PropertyUtils.isReadable() and PropertyUtils.getProperty() not consistent

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33840


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Attachment #14400|0   |1
is obsolete||




--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 21:28 ---
Created an attachment (id=14416)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14416&action=view)
checks that PropertyUtils.isReadable() reports false on innaccessible methods


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r156336 - jakarta/commons/proper/logging/trunk/xdocs/index.xml

[rdonkin]

Author: rdonkin
Date: Sun Mar  6 11:40:23 2005
New Revision: 156336

URL: http://svn.apache.org/viewcvs?view=rev&rev=156336
Log:
Added link to download location

Modified:
jakarta/commons/proper/logging/trunk/xdocs/index.xml

Modified: jakarta/commons/proper/logging/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/index.xml?view=diff&r1=156335&r2=156336
==
--- jakarta/commons/proper/logging/trunk/xdocs/index.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/index.xml Sun Mar  6 11:40:23 
2005
@@ -63,7 +63,7 @@
 Note: this has now been blessed with alpha 
status.


-Please download and test this release. Reports should be directed to the 
commons-dev
+Please download and test 
this release. Reports should be directed to the commons-dev
 mailing list.

 



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

Re: [ANN][configuration]Release candidate 1.1RC2

[Phil Steitz]

Looks good to me.  I checked the sigs (using 
http://www.apache.org/dist/jakarta/commons/configuration/KEYS) and 
hashes and all worked, though the md5 files include trailing cr/lf that 
caused my script to choke.

One small nit:
NOTICE.txt is missing from source and binary distros and jar.
Some test cases generate error messages to standard error when I run 
"ant clean test" though the build succeeds. Don't know if this is a 
problem or not.  It does not look like any test cases actually fail.

Phil
Oliver Heger wrote:
In preparation for a 1.1 release of commons-configuration I have created 
the second release candidate.

The files are available for inspection at
http://www.apache.org/~oheger/commons-configuration-1.1rc2
The name of the tag is CONFIGURATION_1_1RC2.
The release notes (in form of the changes report) can be found at
http://jakarta.apache.org/commons/configuration/changes-report.html
Comments are welcome!
Thanks,
Oliver
-
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]

svn commit: r156335 - jakarta/commons/proper/logging/trunk/xdocs/index.xml

[rdonkin]

Author: rdonkin
Date: Sun Mar  6 11:28:37 2005
New Revision: 156335

URL: http://svn.apache.org/viewcvs?view=rev&rev=156335
Log:
Updated status of 1.0.5 release

Modified:
jakarta/commons/proper/logging/trunk/xdocs/index.xml

Modified: jakarta/commons/proper/logging/trunk/xdocs/index.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/logging/trunk/xdocs/index.xml?view=diff&r1=156334&r2=156335
==
--- jakarta/commons/proper/logging/trunk/xdocs/index.xml (original)
+++ jakarta/commons/proper/logging/trunk/xdocs/index.xml Sun Mar  6 11:28:37 
2005
@@ -58,10 +58,14 @@
 
 
 
-
+

-Note: release candidate is currently under 
preparation.
+Note: this has now been blessed with alpha 
status.

+   
+Please download and test this release. Reports should be directed to the 
commons-dev
+mailing list.
+   
 
 JCL 1.0.5 is a service release adding optional improved automatic memory 
management
 for containers which do not support JCL explicit memory release



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

svn commit: r156334 - jakarta/commons/proper/lang/trunk/RELEASE-NOTES.txt

[bayard]

Author: bayard
Date: Sun Mar  6 11:21:36 2005
New Revision: 156334

URL: http://svn.apache.org/viewcvs?view=rev&rev=156334
Log:
added latest set of fixed issues in Bugz

Modified:
jakarta/commons/proper/lang/trunk/RELEASE-NOTES.txt

Modified: jakarta/commons/proper/lang/trunk/RELEASE-NOTES.txt
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/RELEASE-NOTES.txt?view=diff&r1=156333&r2=156334
==
--- jakarta/commons/proper/lang/trunk/RELEASE-NOTES.txt (original)
+++ jakarta/commons/proper/lang/trunk/RELEASE-NOTES.txt Sun Mar  6 11:21:36 2005
@@ -121,4 +121,10 @@
 31478  Compile error with JDK 5 "enum" is a keyword
 31572  o.a.c.lang.enum.ValuedEnum: 'enum'is a keyword in JDK1.5.0
 31933  ToStringStyle setArrayEnd handled null incorrectly
-
+32133  SystemUtils fails init on HP-UX
+32198  Error in JavaDoc for StringUtils.chomp(String, String)
+32625  Can't subclass EqualsBuilder because isEquals is private
+33067  EqualsBuilder.append(Object[], Object[]) crashes with a 
NullPointerException if an element of the first array is null
+33069  EqualsBuilder.append(Object[], Object[]) incorrectly checks that rhs[i] 
is instance of lhs[i]'s class
+33574  unbalanced ReflectionToStringBuilder
+33737  ExceptionUtils.addCauseMethodName(String) does not check for duplicates.



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

svn commit: r156333 - jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java

[bayard]

Author: bayard
Date: Sun Mar  6 11:05:25 2005
New Revision: 156333

URL: http://svn.apache.org/viewcvs?view=rev&rev=156333
Log:
also commenting out import statement for text so this builds :)

Modified:

jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java

Modified: 
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java?view=diff&r1=156332&r2=156333
==
--- 
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java
 (original)
+++ 
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java
 Sun Mar  6 11:05:25 2005
@@ -25,7 +25,7 @@
 import org.apache.commons.lang.exception.ExceptionTestSuite;
 import org.apache.commons.lang.math.MathTestSuite;
 import org.apache.commons.lang.mutable.MutableTestSuite;
-import org.apache.commons.lang.text.TextTestSuite;
+//import org.apache.commons.lang.text.TextTestSuite;
 import org.apache.commons.lang.time.TimeTestSuite;
 
 /**



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

svn commit: r156332 - jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java

[bayard]

Author: bayard
Date: Sun Mar  6 11:03:31 2005
New Revision: 156332

URL: http://svn.apache.org/viewcvs?view=rev&rev=156332
Log:
commenting out the text tests as they will not be in the next release

Modified:

jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java

Modified: 
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java?view=diff&r1=156331&r2=156332
==
--- 
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java
 (original)
+++ 
jakarta/commons/proper/lang/trunk/src/test/org/apache/commons/lang/AllLangTestSuite.java
 Sun Mar  6 11:03:31 2005
@@ -63,7 +63,7 @@
 suite.addTest(ExceptionTestSuite.suite());
 suite.addTest(MathTestSuite.suite());
 suite.addTest(MutableTestSuite.suite());
-suite.addTest(TextTestSuite.suite());
+//suite.addTest(TextTestSuite.suite());
 suite.addTest(TimeTestSuite.suite());
 return suite;
 }



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

svn commit: r156331 - jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/Interpolation.java

[bayard]

Author: bayard
Date: Sun Mar  6 11:01:38 2005
New Revision: 156331

URL: http://svn.apache.org/viewcvs?view=rev&rev=156331
Log:
added classic do not use this constructor

Modified:

jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/Interpolation.java

Modified: 
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/Interpolation.java
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/Interpolation.java?view=diff&r1=156330&r2=156331
==
--- 
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/Interpolation.java
 (original)
+++ 
jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/text/Interpolation.java
 Sun Mar  6 11:01:38 2005
@@ -22,6 +22,17 @@
 private static final String SYMBOLIC_VALUE_MARKER_END = "}";
 
 /**
+ * Interpolation instances should NOT be constructed in
+ * standard programming. 
+ *
+ * This constructor is public to permit tools that require a JavaBean
+ * instance to operate.
+ */
+public Interpolation() {
+// no init.
+}
+
+/**
  * Interpolates a String to replace variables of the form 
${...}.
  * 
  * This method is useful for enabling simple strings to be modified 
based



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

DO NOT REPLY [Bug 33401] - [lang] atLeast features : public boolean isAtLeast>(parms)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33401





--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 19:58 ---
Oh for closures :)

Frustrating that these 3 methods are really just examples of
apply-this-function-to-an-array. Feels like we have too many of those already in
Lang.

Not necessarily a -1 to the below, just an observation.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33825] - [lang] PATCH-New methods for DateUtils

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33825





--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 19:55 ---
Wondering if this goes far enough.

Looking at the org.apache.commons.lang.math.*Range stuff the other day, I was
wondering if we should have a DateRange class that supports more than just hours
and minutes.

I also really dislike the int approach to the time; 2359 etc. Feels very 
unwieldly.

Should this concept of 'is in range' be applicable to the concept of a Duration,
or to JODA's concept of an Interval, Duration or Period? How far do we then want
to go into this?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[ANN][configuration]Release candidate 1.1RC2

[Oliver Heger]

In preparation for a 1.1 release of commons-configuration I have created 
the second release candidate.

The files are available for inspection at
http://www.apache.org/~oheger/commons-configuration-1.1rc2
The name of the tag is CONFIGURATION_1_1RC2.
The release notes (in form of the changes report) can be found at
http://jakarta.apache.org/commons/configuration/changes-report.html
Comments are welcome!
Thanks,
Oliver
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [math] JAMA update and options

[Phil Steitz]

Martin Cooper wrote:

Not that much duplication exists. What we are *deciding* now is how much
and how to pull it in. The options are as I described earlier in the thread:
0) snippets / classes as needed
1) jar dependency
2) full merge
I am -0 on 2) without support from the JAMA developers or other
volunteers.  The code base is not huge but some of the algorithms are
nontrivial.

Wouldn't (0) be just a subset of (2), and thus lead to the same
potential maintenance issues, albeit on a smaller scale?
Yes, but potentially significantly smaller.  To be specific, what I was 
intitially planning to bring in was code from one class that does QR 
decomposition, to be used in a multiple regression implementation (one 
of the "commonly-used, practical applications" things on the [math] 
wisth list).  I would take the responsibility - gladly accepting help 
from the other [math] contributors - for fully documenting the 
incorporated code and including enough test cases so that "we" could 
effectively maintain and support it.  I am balking at committing to do 
that for the whole code base.

That being
the case, it would seem to me that (1) might make the most sense, so
that each group ([math] and JAMA) can focus on its own code and not
have to worry too much about the other, other than where they come
together.
Could be you are right.  That's why I included that option.  Its 
downsides are

a) sort of goes against [math]'s "minimal dependencies" goal; and
b) some of what we may want to do may require inline work or changes to 
the API

Neither of these is a show-stopper and this is certainly the easiest way 
to go. Thanks for the feedback.

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

Re: [math] JAMA update and options

[Martin Cooper]

On Sun, 06 Mar 2005 10:58:29 -0500, Phil Steitz <[EMAIL PROTECTED]> wrote:
> Henri Yandell wrote:
> > On Sat, 05 Mar 2005 20:24:06 -0500, Mark Diggory <[EMAIL PROTECTED]> wrote:
> >
> >>Even if we have to go through the incubator, I'm convinced that adding
> >>the JAMA codebase into the math library is the best option. IMHO, I'm
> >
> >
> > Can't see why the Incubator would be needed if the aim was to go from
> > Apache/Jakarta/Commons/Math to Apache/Jakarta/Math.
> >
> >  If it was to goto Apache/Math, might be a it more needed in terms of
> > community discussion etc.
> >
> 
> There are two things going on here. One is is deciding where [math] is
> going. Agreed that just moving to Jakarta/Math or even Apache/Math
> really has nothing to do with the incubator. We should probably discuss
> this on a different thread.
> 
> What *does* potentially have to do with the incubator is bringing in a
> substantial code base and hopefully (IMHO) some new contributors.  This
> would be analogous to DB/Axiom and other cases where contributed code
> bases were incubated for eventual inclusion in existing projects.

You mean Axion. A humourous slip on a [math] thread. ;-)

> If we bring in the entire JAMA code base, seems to me we would have to
> bring it through the incubator. Correct me if I am wrong.
> >
> >>convinced that while the JAMA folks were very generous and open to
> >>providing the codebase to the public domain, that further enhancing its
> >>capabilities and providing any user support is not really in their
> >>interest. It would be far more in our interest if we forked the codebase
> >>and supported it.
> >
> >
> > +1 assuming they're not actively supporting theirs anymore.
> 
> But they *are* supporting the code. They are about to release a
> maintenance release with some bug fixes.
> >
> >
> >>Any suggestion that the "JAMA folks" would have to
> >>"agree" to this is not the nature of public domain, IMO reuse of public
> >>domain doesn't require any such acknowledgment, though we should
> >>liberally acknowledge their contribution wherever possible.
> >
> >
> > Or in the nature of the Apache licence. Still, it's polite to do so.
> > Having their blessing is good from a PR point of view of a fork, it
> > makes us the good natured folk who are supporting the tool, and not
> > the evil baddies who are unwilling to work with the original.
> >
> > I assume that we'd still treat JAMA/RngPack as trademarks/names owned by 
> > others.
> >
> 
> 
> 
> >>Note, JAMA is not a large codebase, and is in the public domain. As
> >>such, does this really require the need for an "Incubator project"?
> >
> >
> > Creation of math.apache.org might.
> 
> Lets not mix the discussion of these two.  For now, let's just assume we
> are bringing the code into commons-math.
> >
> > If the JAMA/NIST community were moving their code over to apache.org,
> > then it definitely would. As it is it sounds like we're just talking
> > about an existing part of the Apache community forking a piece of code
> > to use within their exisitng community.
> >
> > Incubation is really about communities and not code, so if the
> > community is already incubated, I don't see why the code would have to
> > be.
> >
> > Would you be looking to pull in the whole thing, or just using the
> > JAMA/NIST code as a place to aquire some snippets/classes? I assume
> > there's a fair amount of duplication already?
> 
> Not that much duplication exists. What we are *deciding* now is how much
> and how to pull it in. The options are as I described earlier in the thread:
> 
> 0) snippets / classes as needed
> 1) jar dependency
> 2) full merge
> 
> I am -0 on 2) without support from the JAMA developers or other
> volunteers.  The code base is not huge but some of the algorithms are
> nontrivial.

Wouldn't (0) be just a subset of (2), and thus lead to the same
potential maintenance issues, albeit on a smaller scale? That being
the case, it would seem to me that (1) might make the most sense, so
that each group ([math] and JAMA) can focus on its own code and not
have to worry too much about the other, other than where they come
together.

--
Martin Cooper


> > While it's public domain, would we still treat it as a contribution
> > (albeit one we pull rather than a contributor push) and maintain a
> > note of contribution in the source or NOTICE?
> 
> Yes, if we do 0), we would add attribution in NOTICE and class headers
> for classes including JAMA code.   JAMA folks would be fine with that.
> 
> Phil
> 
> -
> 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: [chain] questions about various servlet/*Mapper classes

[Joe Germuska]

To fix this, let's first consider how a catalog can be retrieved.
Suppose a command retrieves a catalog from the CatalogFactory (either
the default one or a named one and this is the case when CONFIG_ATTR
is not set), now the problem becomes how it knows the catalog name.
One way is to hard code the catalog name in the command. Another way
is
to retrieve the name from the chain context. I think the later one is
more flexible (especially for a generic command like ServletPathMapper
command), even though it incurs one more step. (This command has a
setCatalogKey method, but I'm not sure how this method can be called.
Since you can't call this method from the containing servlet because
the servlet only knows about the generic command interface.)
Command methods like "setCatalogKey" are generally intended to be set 
during configuration bootstrap time, for example, by the Digester 
process that reads in an XML file...


As for your other comments... to be honest, I've been too busy to 
consider them very carefully, and I think part of my problem is that 
I have never even considered using the ChainServlet classes.  Do you 
have a suggestion for a fix for the code base so that in the next 
release, it will be more practically usable?

Thanks, Joe
--
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

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

Re: [math] JAMA update and options

[Phil Steitz]

Henri Yandell wrote:
On Sat, 05 Mar 2005 20:24:06 -0500, Mark Diggory <[EMAIL PROTECTED]> wrote:
Even if we have to go through the incubator, I'm convinced that adding
the JAMA codebase into the math library is the best option. IMHO, I'm

Can't see why the Incubator would be needed if the aim was to go from
Apache/Jakarta/Commons/Math to Apache/Jakarta/Math.
 If it was to goto Apache/Math, might be a it more needed in terms of
community discussion etc.
There are two things going on here. One is is deciding where [math] is 
going. Agreed that just moving to Jakarta/Math or even Apache/Math 
really has nothing to do with the incubator. We should probably discuss 
this on a different thread.

What *does* potentially have to do with the incubator is bringing in a 
substantial code base and hopefully (IMHO) some new contributors.  This 
would be analogous to DB/Axiom and other cases where contributed code 
bases were incubated for eventual inclusion in existing projects.

If we bring in the entire JAMA code base, seems to me we would have to 
bring it through the incubator. Correct me if I am wrong.

convinced that while the JAMA folks were very generous and open to
providing the codebase to the public domain, that further enhancing its
capabilities and providing any user support is not really in their
interest. It would be far more in our interest if we forked the codebase
and supported it. 

+1 assuming they're not actively supporting theirs anymore.
But they *are* supporting the code. They are about to release a 
maintenance release with some bug fixes.

Any suggestion that the "JAMA folks" would have to
"agree" to this is not the nature of public domain, IMO reuse of public
domain doesn't require any such acknowledgment, though we should
liberally acknowledge their contribution wherever possible.

Or in the nature of the Apache licence. Still, it's polite to do so.
Having their blessing is good from a PR point of view of a fork, it
makes us the good natured folk who are supporting the tool, and not
the evil baddies who are unwilling to work with the original.
I assume that we'd still treat JAMA/RngPack as trademarks/names owned by others.

Note, JAMA is not a large codebase, and is in the public domain. As
such, does this really require the need for an "Incubator project"?

Creation of math.apache.org might.
Lets not mix the discussion of these two.  For now, let's just assume we 
are bringing the code into commons-math.
If the JAMA/NIST community were moving their code over to apache.org,
then it definitely would. As it is it sounds like we're just talking
about an existing part of the Apache community forking a piece of code
to use within their exisitng community.
Incubation is really about communities and not code, so if the
community is already incubated, I don't see why the code would have to
be.
Would you be looking to pull in the whole thing, or just using the
JAMA/NIST code as a place to aquire some snippets/classes? I assume
there's a fair amount of duplication already?
Not that much duplication exists. What we are *deciding* now is how much 
and how to pull it in. The options are as I described earlier in the thread:

0) snippets / classes as needed
1) jar dependency
2) full merge
I am -0 on 2) without support from the JAMA developers or other 
volunteers.  The code base is not huge but some of the algorithms are 
nontrivial.
While it's public domain, would we still treat it as a contribution
(albeit one we pull rather than a contributor push) and maintain a
note of contribution in the source or NOTICE?
Yes, if we do 0), we would add attribution in NOTICE and class headers 
for classes including JAMA code.   JAMA folks would be fine with that.

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

svn commit: r156329 - jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC2

[oheger]

Author: oheger
Date: Sun Mar  6 09:33:39 2005
New Revision: 156329

URL: http://svn.apache.org/viewcvs?view=rev&rev=156329
Log:
Tagging release candidate 1.1RC2

Added:
jakarta/commons/proper/configuration/tags/CONFIGURATION_1_1RC2/
  - copied from r156328, jakarta/commons/proper/configuration/trunk/


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

svn commit: r156328 - in jakarta/commons/proper/configuration/trunk: build.xml project.xml

[oheger]

Author: oheger
Date: Sun Mar  6 09:30:52 2005
New Revision: 156328

URL: http://svn.apache.org/viewcvs?view=rev&rev=156328
Log:
Setting actual version to 1.1RC2

Modified:
jakarta/commons/proper/configuration/trunk/build.xml
jakarta/commons/proper/configuration/trunk/project.xml

Modified: jakarta/commons/proper/configuration/trunk/build.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/build.xml?view=diff&r1=156327&r2=156328
==
--- jakarta/commons/proper/configuration/trunk/build.xml (original)
+++ jakarta/commons/proper/configuration/trunk/build.xml Sun Mar  6 09:30:52 
2005
@@ -41,7 +41,7 @@
   
   
   
-  
+  
   
   
 

Modified: jakarta/commons/proper/configuration/trunk/project.xml
URL: 
http://svn.apache.org/viewcvs/jakarta/commons/proper/configuration/trunk/project.xml?view=diff&r1=156327&r2=156328
==
--- jakarta/commons/proper/configuration/trunk/project.xml (original)
+++ jakarta/commons/proper/configuration/trunk/project.xml Sun Mar  6 09:30:52 
2005
@@ -1,6 +1,6 @@
 
 

Re: [math] JAMA update and options

[Henri Yandell]

On Sat, 05 Mar 2005 20:24:06 -0500, Mark Diggory <[EMAIL PROTECTED]> wrote:
> Even if we have to go through the incubator, I'm convinced that adding
> the JAMA codebase into the math library is the best option. IMHO, I'm

Can't see why the Incubator would be needed if the aim was to go from
Apache/Jakarta/Commons/Math to Apache/Jakarta/Math.

 If it was to goto Apache/Math, might be a it more needed in terms of
community discussion etc.

> convinced that while the JAMA folks were very generous and open to
> providing the codebase to the public domain, that further enhancing its
> capabilities and providing any user support is not really in their
> interest. It would be far more in our interest if we forked the codebase
> and supported it. 

+1 assuming they're not actively supporting theirs anymore.

> Any suggestion that the "JAMA folks" would have to
> "agree" to this is not the nature of public domain, IMO reuse of public
> domain doesn't require any such acknowledgment, though we should
> liberally acknowledge their contribution wherever possible.

Or in the nature of the Apache licence. Still, it's polite to do so.
Having their blessing is good from a PR point of view of a fork, it
makes us the good natured folk who are supporting the tool, and not
the evil baddies who are unwilling to work with the original.

I assume that we'd still treat JAMA/RngPack as trademarks/names owned by others.

> http://www.google.com/search?hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&oi=defmore&q=define:public+domain
> 
> http://math.nist.gov/javanumerics/jama/
> 
> > *Copyright Notice* /This software is a cooperative product of The
> > MathWorks and the National Institute of Standards and Technology
> > (NIST) which has been released to the public domain. Neither The
> > MathWorks nor NIST assumes any responsibility whatsoever for its use
> > by other parties, and makes no guarantees, expressed or implied, about
> > its quality, reliability, or any other characteristic./
> >
> Note, JAMA is not a large codebase, and is in the public domain. As
> such, does this really require the need for an "Incubator project"?

Creation of math.apache.org might.

If the JAMA/NIST community were moving their code over to apache.org,
then it definitely would. As it is it sounds like we're just talking
about an existing part of the Apache community forking a piece of code
to use within their exisitng community.

Incubation is really about communities and not code, so if the
community is already incubated, I don't see why the code would have to
be.

Would you be looking to pull in the whole thing, or just using the
JAMA/NIST code as a place to aquire some snippets/classes? I assume
there's a fair amount of duplication already?

While it's public domain, would we still treat it as a contribution
(albeit one we pull rather than a contributor push) and maintain a
note of contribution in the source or NOTICE?

Let me know if you need anything Phil.

Hen

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

DO NOT REPLY [Bug 33550] - [digester] Add support for CallMethodRule with target offset in xml rules

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33550





--- Additional Comments From [EMAIL PROTECTED]  2005-03-06 18:05 ---
Created an attachment (id=14415)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14415&action=view)
unit test for xmlrules use of call-method-rule targetoffset attrib


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: [math] JAMA update and options

[Phil Steitz]

Kim,
See  and
 for a background on the apache incubator.
As Brian B likes to point out, we have *two* things to think about when 
it comes to incorporating code from / working with other communities:
1) doing the right legal thing
2) doing the right thing

It could be that we can *legally* pull in the entire JAMA code base 
without any involvement or support from the JAMA developers, but I at 
least don't think that would satisfy 2).  I think that would be bad for 
both JAMA and us. Are we ready to support all of that code? We need to 
build community as well as code here and I think it would be much better 
to either get the code + community from JAMA to join us or to follow one 
of the other options that I presented below (jar dependency or limited 
inclusion with mutual back-porting).

Phil
Kim van der Linde wrote:
Ok, what the hell is an incubater project. I have integrated the 
different decompositions already to the RealMatrix and they work fine.

So, just go ahead I would say.
kim
Mark Diggory wrote:
Even if we have to go through the incubator, I'm convinced that adding 
the JAMA codebase into the math library is the best option. IMHO, I'm 
convinced that while the JAMA folks were very generous and open to 
providing the codebase to the public domain, that further enhancing 
its capabilities and providing any user support is not really in their 
interest. It would be far more in our interest if we forked the 
codebase and supported it. Any suggestion that the "JAMA folks" would 
have to "agree" to this is not the nature of public domain, IMO reuse 
of public domain doesn't require any such acknowledgment, though we 
should liberally acknowledge their contribution wherever possible.

http://www.google.com/search?hl=en&lr=&client=firefox-a&rls=org.mozilla:en-US:official&oi=defmore&q=define:public+domain 

http://math.nist.gov/javanumerics/jama/
*Copyright Notice* /This software is a cooperative product of The 
MathWorks and the National Institute of Standards and Technology 
(NIST) which has been released to the public domain. Neither The 
MathWorks nor NIST assumes any responsibility whatsoever for its use 
by other parties, and makes no guarantees, expressed or implied, 
about its quality, reliability, or any other characteristic./

Note, JAMA is not a large codebase, and is in the public domain. As 
such, does this really require the need for an "Incubator project"?

Thanks Phil for taking such an initiative.
My $0.02,
-Mark
Phil Steitz wrote:
I have gone back and forth a few times with one of the JAMA 
developers at NIST (Bruce Miller) and legal-discuss and have finally 
asked the ASF board for a ruling on whether or not we can start 
pulling in some JAMA code. I wanted to start with the QR class, so we 
can use that to get multiple regression implemented with decent 
numerics.

Before we start down this path, though I want to present some logical 
alternatives and get others' reactions to them.  Rather than pulling 
in bits of implementation code, we could

1) Introduce a jar dependency on JAMA and wrap / extend / directly 
use the stuff we need.  For the QR use case, there will be no 
performance / efficiency hit from this. For some of the other 
RealMatrix uses, this might be tricky.

2) Bring in the full code base.  This would probably result in a side 
trip through the incubator and might provide the occasion to get us 
kicked out of commons (I am sure there are some who will be happy to 
see us go :-) but that might be a good thing.  I don't know yet if 
the JAMA guys would go for this, am interested in opinions of others 
here.

If I get the go ahead from the board, we will need to decide between
0) fork selected stuff into [math] and pass bug fixes back and forth 
with JAMA

and 1) or 2).  WDYT?
Note that the same considerations apply to RngPack.
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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


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

Re: [math] JAMA update and options

[robert burrell donkin]

On Sun, 2005-03-06 at 03:38, Kim van der Linde wrote:
> Ok, what the hell is an incubater project.

http://incubator.apache.org/

the active support of an ASF member would be required

- robert


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

[lang]/[servlet] Doing some tickling

[Frank W. Zammetti]

Hope everyone is having a good weekend!
I just wanted to drop a line and kind of tickle some devs on two tickets 
I had opened:

[lang] 33825 - New methods for DateUtils
[servlet] 33676 - SessionUtils and new methods for RequestUtils
Just curious to see if anyone had looked at them (there are no comments 
posted on them, but that doesn't necessarily indicate no one has looked 
at them).  Thanks!

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31478] - [lang] Compile error with JDK 5 "enum" is a keyword

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=31478


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|Compile error with JDK 5|[lang] Compile error with
   |"enum" is a keyword |JDK 5 "enum" is a keyword




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 31478] - Compile error with JDK 5 "enum" is a keyword

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=31478


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||33866
  nThis||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33866] - [lang] enum package is not compatible with 1.5 jdk

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33866


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||31478




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33866] - [lang] enum package is not compatible with 1.5 jdk

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33866


[EMAIL PROTECTED] changed:

   What|Removed |Added

  BugsThisDependsOn||30503




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 30503] - [collections] compile failes with jdk 1.5 due to "enum"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=30503


[EMAIL PROTECTED] changed:

   What|Removed |Added

OtherBugsDependingO||33866
  nThis||




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

DO NOT REPLY [Bug 33866] - [lang] enum package is not compatible with 1.5 jdk

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=33866


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|enum package is not |[lang] enum package is not
   |compatible with 1.5 jdk |compatible with 1.5 jdk




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

[beanutils] patch for test case failures under maven

[Simon Kitching]

Hi,

I have found that running "maven test" for beanutils reports a failure
of 3 test cases.

(a) BeanificationTestCase and LocaleBeanificationTestCase both fail to
load a test class using the code:
   ClassLoader loader = new ClassLoader() {};
   Class myClass = loader.loadClass(
 "org.apache.commons.beanutils.BetaBean");

I believe the problem is that maven runs the unit tests within a custom
classloader or somesuch, and so the above code which creates a
classloader whose parent is the *system* classloader can't find the test
case classes.

Changing the above to:
   ClassLoader loader = new ClassLoader(
 this.getClass().getClassLoader()) {};
   ...
resolves the issue.

(b) in the test/.../locale/converters directory, file
"BaseLocaleConverterTestCase.java" doesn't actually define any test
cases at all; it is just intended as a base class for the other tests to
extend. But junit regards it as an error for a TestCase class not to
have any tests. Simply adding a dummy test method resolves this. (NB:
the alternative would be to rename the class [eg to
"BaseLocaleConverterTester"] and then change each class that inherits
from it to match the new name which is probably a "purer" solution but
much more hassle.



Are there any objections to me committing these changes to beanutils?

I have also been working on bug# 18294. Are the beanutils maintainers ok
with me adding myself to the "developers" list for beanutils and
applying the necessary changes for that?

Thanks,

Simon



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

[GUMP@brutus]: Project commons-jelly-tags-xml (in module commons-jelly) failed

[commons-jelly-tags-xml development]

To whom it may engage...

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

Project commons-jelly-tags-xml has an issue affecting its community integration.
This issue affects 12 projects,
 and has been outstanding for 12 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-jelly-tags-define :  Commons Jelly
- commons-jelly-tags-html :  Commons Jelly
- commons-jelly-tags-http :  Commons Jelly
- commons-jelly-tags-jaxme :  Commons Jelly
- commons-jelly-tags-jetty :  Commons Jelly
- commons-jelly-tags-jface :  Commons Jelly
- commons-jelly-tags-jsl :  Commons Jelly
- commons-jelly-tags-swing :  Commons Jelly
- commons-jelly-tags-xml :  Commons Jelly
- commons-jelly-tags-xmlunit :  Commons Jelly
- maven :  Project Management Tools
- maven-bootstrap :  Project Management Tools


Full details are available at:

http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [commons-jelly-tags-xml-06032005.jar] identifier set to 
project name
 -DEBUG- Dependency on xml-xerces exists, no need to add for property 
maven.jar.xerces.
 -DEBUG- (Gump generated) Maven Properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/build.properties
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.xml
 -DEBUG- Maven project properties in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/project.properties
 -INFO- Project Reports in: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/commons-jelly/commons-jelly-tags-xml/gump_work/build_commons-jelly_commons-jelly-tags-xml.html
Work Name: build_commons-jelly_commons-jelly-tags-xml (Type: Build)
Work ended in a state of : Failed
Elapsed: 13 secs
Command Line: maven --offline jar 
[Working Directory: 
/usr/local/gump/public/workspace/commons-jelly/jelly-tags/xml]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-06032005.jar:/usr/local/gump/public/workspace/commons-jelly/target/commons-jelly-06032005.jar:/usr/local/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-06032005.jar:/usr/local/gump/public/workspace/jakarta-commons/jexl/dist/commons-jexl-06032005.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/dom4j/build/dom4j.jar:/usr/local/gump/public/workspace/jaxen/target/jaxen-06032005.jar
-
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:compile:
[echo] Compiling to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes
[echo] 
==

  NOTE: Targetting JVM 1.4, classes
  will not run on earlier JVMs

==
  
[javac] Compiling 16 source files to 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/classes

java:jar-resources:

test:prepare-filesystem:
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-classes
[mkdir] Created dir: 
/home/gump/workspaces2/public/workspace/commons-jelly/jelly-tags/xml/target/test-reports

test:test-resources:
Copying 36 files to 
/home/gump/workspaces2/public/workspace/commons-je