[ANNOUNCEMENT] Apache Commons DbUtils 1.3 Released

2009-11-12 Thread Dan Fabulich 


The Commons DbUtils team is pleased to announce the commons-dbutils-1.3 
release!


DbUtils is a package of Java utility classes for easing JDBC development.

Changes in this version include:

New features:
o Java 1.5 generics and varargs  Issue: DBUTILS-48.

Fixed Bugs:
o Fixed error message in QueryRunner#rethrow  Issue: DBUTILS-60.

Changes:
o BeanProcessor#mapColumnsToProperties now prefers to use column labels 
over column names (where aliases are not set, these should be identical) 
Issue: DBUTILS-57.
o Setting pmdKnownBroken in QueryRunner constructor now completely ignores 
ParameterMetaData Issue: DBUTILS-58.



Have fun!
-Commons DbUtils team


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Updating dbutils download page

2009-11-12 Thread Dan Fabulich 


The release is almost finished, but I still can't get the Maven 1 build to 
work in commons-build trunk so I can bump the version number here: 
http://commons.apache.org/downloads/download_dbutils.cgi


Last time Henri ran the build for me... Any ideas?

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] [RESULT] Release of DbUtils 1.3 RC4

2009-11-11 Thread Dan Fabulich 


Unanimous +1s.

Binding: Joerg Schaible, Luc Maisonobe, Oliver Heger
Non-binding: Dan Fabulich, Julien Ayme, Liam Coughlin

-- Forwarded message --
Date: Sun, 8 Nov 2009 10:09:16 -0800 (Pacific Standard Time)
From: Dan Fabulich 
Reply-To: Commons Developers List 
To: Commons Developers List 
Subject: [VOTE] Release of DbUtils 1.3 RC4


This release includes support for Java5 generics and varargs.

In RC3 I accidentally added a dependency on Java 1.6 while fixing FindBugs 
errors; in RC4 I fixed that bug.


As noted in earlier RCs, I believe 1.3 to be a backwards compatible binary, but 
I'm still only 99% sure of this; clirr reports a bunch of compatibility errors 
that look like nonsense. I did run the compiled 1.2 tests against 1.3 and it 
looks OK.


+1 from me!

--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_3_RC4/

Site:

http://people.apache.org/builds/commons/dbutils/1.3/RC4/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.3/RC4/staged/commons-dbutils/commons-dbutils/1.3/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.3 RC3

2009-11-08 Thread Dan Fabulich 

D'oh!  Good catch...

Oliver Heger wrote:


I tried to build the sources on a JDK 1.5 and got the following errors:

D:\data\projects\OpenSource\dbutils\commons-dbutils-1.3-src\src\java\org\apache\
commons\dbutils\wrappers\SqlNullCheckedResultSet.java:[216,53] cannot find 
symbol

symbol  : method copyOf(byte[],int)
location: class java.util.Arrays

D:\data\projects\OpenSource\dbutils\commons-dbutils-1.3-src\src\java\org\apache\
commons\dbutils\wrappers\SqlNullCheckedResultSet.java:[452,31] cannot find 
symbol

symbol  : method copyOf(byte[],int)
location: class java.util.Arrays

The Arrays.copyOf() method was introduced in JDK 1.6. Shouldn't DbUtils 1.3 
be compatible with Java 1.5?


Oliver

Dan Fabulich schrieb:


This release includes support for Java5 generics and varargs.

For RC3 I fixed the CheckStyle and FindBugs errors, except for the "bad 
practice" bug of using getClass().getResourceAsStream(), which would 
probably require an API change.


As noted in earlier RCs, I believe 1.3 to be a backwards compatible binary, 
but I'm still only 99% sure of this; clirr reports a bunch of compatibility 
errors that look like nonsense. I did run the compiled 1.2 tests against 
1.3 and it looks OK.


+1 from me!

PS I, uh, accidentally overwrote 1.3 RC2 while uploading this version. You 
can still rebuild 1.3 RC2 from source if you need to see the binary diffs, 
but RC2 won't be officially released, so I don't think any real harm has 
been done.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_3_RC3/ 


Site:

http://people.apache.org/builds/commons/dbutils/1.3/RC3/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.3/RC3/staged/commons-dbutils/commons-dbutils/1.3/ 


[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release of DbUtils 1.3 RC4

2009-11-08 Thread Dan Fabulich 


This release includes support for Java5 generics and varargs.

In RC3 I accidentally added a dependency on Java 1.6 while fixing FindBugs 
errors; in RC4 I fixed that bug.


As noted in earlier RCs, I believe 1.3 to be a backwards compatible binary, but 
I'm still only 99% sure of this; clirr reports a bunch of compatibility errors 
that look like nonsense. I did run the compiled 1.2 tests against 1.3 and it 
looks OK.


+1 from me!

--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_3_RC4/

Site:

http://people.apache.org/builds/commons/dbutils/1.3/RC4/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.3/RC4/staged/commons-dbutils/commons-dbutils/1.3/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release of DbUtils 1.3 RC3

2009-11-07 Thread Dan Fabulich 


This release includes support for Java5 generics and varargs.

For RC3 I fixed the CheckStyle and FindBugs errors, except for the "bad 
practice" bug of using getClass().getResourceAsStream(), which would 
probably require an API change.


As noted in earlier RCs, I believe 1.3 to be a backwards compatible 
binary, but I'm still only 99% sure of this; clirr reports a bunch of 
compatibility errors that look like nonsense. I did run the compiled 1.2 
tests against 1.3 and it looks OK.


+1 from me!

PS I, uh, accidentally overwrote 1.3 RC2 while uploading this version. 
You can still rebuild 1.3 RC2 from source if you need to see the binary 
diffs, but RC2 won't be officially released, so I don't think any real 
harm has been done.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_3_RC3/

Site:

http://people.apache.org/builds/commons/dbutils/1.3/RC3/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.3/RC3/staged/commons-dbutils/commons-dbutils/1.3/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.3 RC2

2009-11-07 Thread Dan Fabulich 

James Carman wrote:


If you don't fix the exposure of internals, it might mess things up
later if you want to change the implementation.  I'd say those should
be fixed.


It's a little late for that... this bug was in version 1.2.

But I fixed it anyway as DBUTILS-63 in revision 833753.  I'll roll out a 
new RC.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] binary compatibility

2009-11-04 Thread Dan Fabulich 

Jörg Schaible wrote:


Maybe you can use the src tarball from 1.2, change group and artifact id to
something local, drop the Java source from main and add 1.3-SNAPSHOT as
dependency. Then you should be able to run with this POM the tests of 1.2
with code base of 1.3.


That test passes, though I don't think that's technically a test of binary 
compatibility, since it's compiling the tests against 1.3.


So for my second test I did "mvn clean test" on the 1.2 source, then 
deleted the "classes" directory and added 1.3 as a dependency, so the 
previously compiled test classes would run against 1.3 binaries.  That 
test passed, too.


I think we're good!

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] Java5 branch landed to trunk; release tomorrow?

2009-11-03 Thread Dan Fabulich 

Julien Aymé wrote:


I've submitted a patch for DBUTILS-54 and DBUTILS-57, which can be
added to the release if someone (Dan? ;-) ) has the time to review
them.

I'll try to submit a patch for DBUTILS-50 later this evening, but I
think this will require a little more time and thoughts.

https://issues.apache.org/jira/browse/DBUTILS-54
https://issues.apache.org/jira/browse/DBUTILS-57
https://issues.apache.org/jira/browse/DBUTILS-50


I submitted your patch for DBUTILS-57, but I -1 the patch for DBUTIL-54... 
it's just too much complexity for a "Minor" issue.


I think DBUTILS-50 will also be controversial (Liam had argued against it) 
so at this point I'd like to move ahead with a release candidate for 1.3. 
DBUTILS-54 and DBUTILS-50 can be handled in a later release, IMO.  (I'd 
like to do the release this week; I've blocked out time during ApacheCon 
to think about this.)


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] binary compatibility

2009-11-03 Thread Dan Fabulich 

Jörg Schaible wrote:


Is it binary backward compatible?


I think it is, but I'm not 100% certain; it's confusing.

I ran clirr on dbutils-1.2 and my locally built 1.3-SNAPSHOT; it found one 
clear compatibility error which I just fixed (DBUTILS-61).  This is what 
it says as of r832529:


INFO: 7011: org.apache.commons.dbutils.ProxyFactory: Method 'public 
java.lang.Object newProxyInstance(java.lang.Class, 
java.lang.reflect.InvocationHandler)' has been added
INFO: 7011: org.apache.commons.dbutils.ResultSetIterator: Method 'public 
java.lang.Iterable iterable(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.ResultSetIterator: Return type of 
method 'public java.lang.Object next()' has been changed to java.lang.Object[]
INFO: 7011: org.apache.commons.dbutils.ResultSetIterator: Method 'public 
java.lang.Object next()' has been added
INFO: 8000: org.apache.commons.dbutils.handlers.AbstractKeyedHandler: Class 
org.apache.commons.dbutils.handlers.AbstractKeyedHandler added
ERROR: 7006: org.apache.commons.dbutils.handlers.AbstractListHandler: Return 
type of method 'public java.lang.Object handle(java.sql.ResultSet)' has been 
changed to java.util.List
INFO: 7011: org.apache.commons.dbutils.handlers.AbstractListHandler: Method 
'public java.lang.Object handle(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.ArrayHandler: Return type of 
method 'public java.lang.Object handle(java.sql.ResultSet)' has been changed to 
java.lang.Object[]
INFO: 7011: org.apache.commons.dbutils.handlers.ArrayHandler: Method 'public 
java.lang.Object handle(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.ArrayListHandler: Return type 
of method 'protected java.lang.Object handleRow(java.sql.ResultSet)' has been 
changed to java.lang.Object[]
INFO: 7011: org.apache.commons.dbutils.handlers.ArrayListHandler: Method 
'protected java.lang.Object handleRow(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.BeanListHandler: Return type 
of method 'public java.lang.Object handle(java.sql.ResultSet)' has been changed 
to java.util.List
INFO: 7011: org.apache.commons.dbutils.handlers.BeanListHandler: Method 'public 
java.lang.Object handle(java.sql.ResultSet)' has been added
INFO: 5000: org.apache.commons.dbutils.handlers.KeyedHandler: Added 
org.apache.commons.dbutils.handlers.AbstractKeyedHandler to the list of 
superclasses
INFO: 7000: org.apache.commons.dbutils.handlers.KeyedHandler: Method 'protected 
java.util.Map createMap()' is now implemented in superclass 
org.apache.commons.dbutils.handlers.AbstractKeyedHandler
ERROR: 7006: org.apache.commons.dbutils.handlers.KeyedHandler: Return type of 
method 'protected java.lang.Object createRow(java.sql.ResultSet)' has been 
changed to java.util.Map
INFO: 7011: org.apache.commons.dbutils.handlers.KeyedHandler: Method 'protected 
java.lang.Object createRow(java.sql.ResultSet)' has been added
INFO: 7003: org.apache.commons.dbutils.handlers.KeyedHandler: Method 'public 
java.lang.Object handle(java.sql.ResultSet)' has been removed, but an inherited 
definition exists.
ERROR: 7006: org.apache.commons.dbutils.handlers.MapHandler: Return type of 
method 'public java.lang.Object handle(java.sql.ResultSet)' has been changed to 
java.util.Map
INFO: 7011: org.apache.commons.dbutils.handlers.MapHandler: Method 'public 
java.lang.Object handle(java.sql.ResultSet)' has been added
ERROR: 7006: org.apache.commons.dbutils.handlers.MapListHandler: Return type of 
method 'protected java.lang.Object handleRow(java.sql.ResultSet)' has been 
changed to java.util.Map
INFO: 7011: org.apache.commons.dbutils.handlers.MapListHandler: Method 
'protected java.lang.Object handleRow(java.sql.ResultSet)' has been added

All of the errors are complaints about covariant return types. In each 
case, something that used to return an Object now returns a more specific 
type (e.g. List or Object[]).


But it's confusing, because Java handles covariant return types by 
generating replacement methods in the bytecode.  So there IS still a 
method that returns Object in the bytecode.


For example, according to Jad, BeanListHandler.class decompiles like this:

  public List handle(ResultSet rs) throws SQLException {
return convert.toBeanList(rs, type);
  }

  public volatile Object handle(ResultSet resultset) throws SQLException {
return handle(resultset);
  }

Strangely, Clirr is reporting this as an ERROR that the method has 
changed, followed by an INFO remark that a new method was added that just 
happens to be exactly like the old method!  (I guess the new signature 
isn't exactly the same, since it is marked "volatile" ...?)


I believe none of these errors are really errors.  I tested this by 
creating a subclass of KeyedHandler like this:


  public class MyKeyedHandler extends KeyedHandler {
public boolean hit = false;
@Override
protected Object createRow(ResultSet rs) th

[dbutils] Java5 branch landed to trunk; release tomorrow?

2009-11-02 Thread Dan Fabulich 


In r832220 I merged the sandbox/dbutils/java5 branch to 
proper/dbutils/trunk.  The build works and has no compiler warnings.


I've also fixed bug DBUTILS-58, which provides a workaround for bug 
DBUTILS-56.


https://issues.apache.org/jira/browse/DBUTILS-56 
https://issues.apache.org/jira/browse/DBUTILS-58


At this point, I think I'd be happy to cut a release...  I'll fire up an 
RC at ApacheCon Hackathon tomorrow unless somebody (Julien?) identifies 
some other bugs that need fixing.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] Ping for next release ?

2009-10-22 Thread Dan Fabulich 


I got distracted; it's been on my todo list for months now...

I'll try to get around to it in the next three weeks or so.

-Dan


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] Consider moving Mock classes from src/test to src/java

2009-09-01 Thread Dan Fabulich 

Julien Aymé wrote:


What do you think? Should I create a JIRA issue for this?


Filing a JIRA issue wouldn't hurt, but I'm not sure we'd want to ship our 
mocks as part of the product.  I think there are better implementations of 
MockResultSet out there (SQLUnit, Mockrunner, etc.)


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: Commons Dbutils: Request feedback for possible patch; handling nested beans.

2009-07-22 Thread Dan Fabulich 
 // create
nestedBeanValue = nestedBeanType.newInstance();
// set value to new instance
fieldSetterMethod.invoke(bean, nestedBeanValue);
}
System.out.println(" property :" + property
+ " target nested Bean: " + nestedBeanValue);
Class propType = property.getPropertyType();
Object targetValue = this.processColumn(rs, rs
.findColumn(property.getName()), propType);
if (propType != null && targetValue == null
&& propType.isPrimitive()) {
targetValue = primitiveDefaults.get(propType);
}
this.callSetter(nestedBeanValue, property, targetValue);
} catch (Exception e) {
e.printStackTrace();
throw new SQLException(e.getMessage());
}
}
return bean;
}


thanks,
Anil Philip

-Original Message-
From: Liam Coughlin [mailto:lscough...@gmail.com]
Sent: Wednesday, July 22, 2009 1:26 PM
To: Commons Developers List
Subject: Re: Commons Dbutils: Request feedback for possible patch; handling 
nested beans.

The default BeanHandler is not a full mapping solution and I'm not sure you
really want it to be -- that's a case where it might be in your best
interest to implement a custom Handler.

Cheers
-L

On Wed, Jul 22, 2009 at 12:59 PM, Philip, Anil - Kansas City, MO <
anil.phi...@kcc.usda.gov> wrote:



Here is the example - I had an idea and implemented a possible fix that
works. I would like to know before I submit a patch, whether it really is a
solution or if there is a better way. In short, can I get feedback here?

Problem:
Some of our beans contain object references to other beans. Those nested
beans may have properties that are intended to be filled in by one or more
fields from a query. However, since it is not on the surface, Dbutils cannot
find where the property is and so the nested property remains unfilled.

Example:
Consider a table Moods to track our demeanor while we engage in an
activity. So it has two columns; face (demeanor) and activity.

FaceActivity
-   
huffing Jog
smile   Work
engrossed   movie
sad Cry
distant distracted
bored   waiting

Bean Foo contains an object reference to an instance - a bean- of class
Bar. Foo contains data field or property 'face', and Bar contains the
property 'activity', that we want to fill from this query:
"select face, activity from Mood"

public class Foo {
   private String face;
   private Bar bar;
   public String getFace() {return face;}
   public void setFace(String face) {this.face = face;}
   public void setBar(Bar bar) {this.bar = bar;}
   public Bar getBar() {return bar;}
}
public class Bar {
   private String activity;
   public String getActivity() {return activity;}
   public void setActivity(String activity) {this.activity = activity;}
}

Old way:
QueryRunner runner = new QueryRunner();
BeanHandler bh = new BeanHandler(Foo.class);
Foo foo = (Foo) runner.query(connection,
   "select face, activity from Mood", bh);

Result:
Foo.bar is null and its fields are unpopulated.

thanks,
Anil Philip

-Original Message-
From: Dan Fabulich [mailto:d...@fabulich.com]
Sent: Tuesday, July 21, 2009 7:13 PM
To: Commons Developers List
Subject: Re: Commons Dbutils: Request feedback for possible patch; handling
nested beans.

Philip, Anil - Kansas City, MO wrote:


We use dbutils in my team and found a problem when a bean has nested

object references.

The properties in the nested bean are obviously not filled in.


File a bug with an example?  I'm not sure I quite understand your
scenario.

http://issues.apache.org/jira/browse/DBUTILS
(You need to login to file a bug.)

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Commons Dbutils: Request feedback for possible patch; handling nested beans.

2009-07-21 Thread Dan Fabulich 

Philip, Anil - Kansas City, MO wrote:


We use dbutils in my team and found a problem when a bean has nested object 
references.
The properties in the nested bean are obviously not filled in.


File a bug with an example?  I'm not sure I quite understand your 
scenario.


http://issues.apache.org/jira/browse/DBUTILS
(You need to login to file a bug.)

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: AW: AW: [releasing] SVN Tag creeated by maven

2009-05-13 Thread Dan Fabulich 

Mark Struberg wrote:



You are right, but maybe we mix up two things:

a) In almost all other SCMs (except SVN) a tag is a 'reference' to a 
specific version. In SVN it's a copy (virtually a readonly branch) so 
you cannot have multiple tags on the same revision. -> the rettagging 
isn't valid because it's _not_ physically the same.


This is a philosophical question of source code identity.  Is a copy of 
source code "the same" as the original?  What about a symlink?  SVN copies 
are "lightweight;" they're more like symlinks than true copies.  Questions 
like these have no right answer IMO.


b) for SVN it's imho perfectly ok to delete a copy which is erronous, 
because you don't touch trunk here. So a RC which never got deployed to 
another area than staging may imho safely be deleted/rollbacked.


It's not "unsafe" to delete/recreate a tag, but it does violate the 
convention that tags are read-only copies.  It's certainly not ideal.


Maybe a mixed scenario would work. Doing development, calling a 
X-RC-[1-n] if all is ok, do a X release:prepare release:stage, call a 
vote on that stage, if it passes do a release:perform. That should 
combine the best parts of both processes, wdyt?


We can't do it quite like that, because release:perform creates a new 
binary; we have to vote on the final binary.  Typically Apache projects 
who use release:stage use it *instead* of release:perform.


(The way we use it, release:perform is run with a -Prc profile, so it 
basically is release:stage for all intents and purposes.)


But let's suppose we did what you said, except don't do the final 
release:perform, just release:prepare, then release:stage, vote, and then 
manually release the staged RC (perhaps using maven-stage-plugin).


Even then, the tag riddle is in release:prepare.  release:prepare is the 
one that creates the tag, unfortunately.  If you need to do multiple RCs, 
you have to run release:prepare multiple times, and that means 
deleting/recreating the tag every time like we do today.


If you think deleting/recreating the tag is totally fine, then this won't 
bother you; we'll just stick with the release process we have today.


But if it bothers you that our tags are mutable, then you'll yearn for 
some better solution; arguably, Maven is unwilling/unable to provide that 
solution right now.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: AW: [releasing] SVN Tag creeated by maven

2009-05-13 Thread Dan Fabulich 

Mark Struberg wrote:



So if you tag the RC as DBUTILS_1_2_RC1 then the 
source code includes "RC1".  If you then later copy that tag to "DBUTILS_1_2" 
the source code will still say "RC1".


Sorry Dan, there are a lot things missing in mavens release process, but 
this very thing is imho not a problem with maven but with the weirdness 
of SVN handling tags. If you make a svn:copy, then you _will_ 
create_a_new_tag_! So pom.xml still contains exactly that what has been 
released, and not only pom.xml, but _ALL_ release artifacts e.g. the 
sources.tar.gz, etc. Renaming tags, moving tags etc is essentially a 
no-no if you don't perform a build from that exact location afterwards. 
SVN guaranties atomic operations - at least _almost_ always. And I've 
seen a lot of weirdness in my last 20 years of using SCMs where this 
'almost' did matter a lot ;) If you have to make sure 100%, then you 
have to build from the exact location.


I agree that subversion tags are silly, and on many projects I own, I 
don't use them; I just record the revision number in a wiki and call that 
a "tag."


With that said, I don't actually want to release a binary from one tag and 
then copy to another.  (I didn't mean to suggest that I wanted that in my 
previous reply.)


I just wish the source code files didn't contain a line saying "This is 
RC3"; because then, when we decide that RC3 is final, I have to change the 
code one last time to make it actually final.


What's wrong with the maven-staging? You tag as if you do a release 
(with exact that tag in SVN and pom.xml) but the results will not be 
deployed to the final repo but only to a staging repo. Maybe I only 
missed that part of the discussion, sorry for the noise then.


To recap: Performing the release "as if" it were final is a wise 
workaround, but when you use the release plugin to do it, it will create a 
tag for you, which creates a riddle as to whether you want to call the tag 
"_RC3" or whether you want to just give it the final name, forcing you to 
modify the tag (delete/recreate) if RC4 is necessary.  (The idea here 
being that deleting/recreating tags is bad.)


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [releasing] SVN Tag creeated by maven

2009-05-13 Thread Dan Fabulich 

sebb wrote:

Is it possible to create a tag with RC1, but leave the POM with 
DBUTILS_1_2?


If you use release:prepare to create a tag, it will insert *that* tag, 
whatever it is, in the pom source.


Of course, you can always do what the release plugin does by hand.  That's 
a surprisingly viable option, especially for single-module projects like 
dbutils.  All the plugin does is:


* run some verification checks
* change the version number and the POM source link, check-in
* create the tag
* change the version number to the next development version, check-in

For small projects I maintain, I don't use the release plugin, partly for 
this very reason.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [releasing] SVN Tag creeated by maven

2009-05-13 Thread Dan Fabulich 

sebb wrote:


However, if the directory names within the archives contain the -RC2
suffix, then that is a different matter. Maybe a Maven expert can give
advice here on how to work with immutable tags?


I consider myself reasonably expert with Maven, and my opinion is that 
Maven's release process is entirely wrong and does not embody a best 
practice.  :-(


The problem here is that the source code (the pom.xml file) contains the 
path to the source code in subversion.  So if you tag the RC as 
DBUTILS_1_2_RC1 then the source code includes "RC1".  If you then later 
copy that tag to "DBUTILS_1_2" the source code will still say "RC1".


Since you can't modify the source code after the vote, your best bet is to 
create the RC with the final location for the tag and delete/re-tag for 
each RC. :-(


IMO, it's entirely wrong for the pom.xml source code to describe the 
location of the source code.  The reason Maven wants this information 
there is so when it goes to deploy (either for snapshots or releases) the 
deployed .pom file in the Maven repository will contain a link to the 
source code.


That feature should be implemented by inserting the source link in the 
deployed .pom file at deploy time.  (It should be auto-detected, or read 
from some non-checked-in location or manually specified at that time.)


At a more philosophical level, the only reason Maven *has* a release 
plugin is because its release philosophy is wrong: the Maven philosophy is 
to make changes to the source code at release time, which is fundamentally 
a bad idea which I hope we can fix some day.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

RE: [all] Rebooting commons projects

2009-05-12 Thread Dan Fabulich 

Gary Gregory wrote:

Ah, em, we cannot do exactly that of course but the idea is that a new 
project/version can reflect two ideas: A new JRE requirement and/or a 
new implementation of the project SO different to warrant a new project.


I also don't like "-ng" or even "blah2".

Specifically, I don't believe that a "new" project should launch with a 
nearly identical or derivative name.


If you feel like you'd want to call it "lang2" or "lang-ng" then just call 
it lang 2.0 or 3.0 or whatever and keep a lang-1.x branch around for 
stability fixes.


On the other hand, if you think it's different enough to warrant an 
entirely new name, like renaming "LDAP Studio" to "Directory Studio", then 
go ahead and do that.


Just my two cents...

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [releasing] SVN Tag creeated by maven

2009-05-12 Thread Dan Fabulich 
When I ran it, the release plugin prompted me for the tag name to create. 
Rather than accept defaults, I manually typed in the appropriate tag name.


-Dan

Christian Grobmeier wrote:


Hi,
currently the
mvn -Prc release:perform

creates a tag with the release name instead of f.e. commons-compress-1_0-RC1.

1) Do I have to remove the tag commons-compress-1_0 manually when
doing a second release candidate? Just want to make sure, don't want
to break the rules.

2) Is it really good to have a tag named like this instead with a
suffix RC1 or whatever?

And yes, I will update:
http://wiki.apache.org/commons/CreatingReleases
with your answers :-)

Best,
Christian

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-build site

2009-05-01 Thread Dan Fabulich 

Henri just ran the build for me. :-(

Rahul Akolkar wrote:


On Thu, Apr 30, 2009 at 1:30 AM, Dan Fabulich  wrote:


Well, there's no pom.xml in there that I can see.  Maven 1.0.2 reports a
similar error:




From memory, its m1.0.2 (which you have), maven-xdoc-plugin 1.9.2
(which you also have) and JDK 1.4 or 1.5 (but not 1.6, ISTR failures
with 1.6). If you figure out what the qdox error is below, drop a line
here for the archives.

-Rahul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[dbutils] Version number for next release

2009-05-01 Thread Dan Fabulich 


With the release of DbUtils 1.2, we're actually basically already ready to 
do another release of DbUtils, this time with enhancements specific to 
Java 5 (generics + varargs).


The new Java 5 API is 100% compatible at runtime with the API of DbUtils 
1.2 (or, at least, I tried to do so, I'll be sure to use API comparison 
tools prior to release and fix any bugs I find).


I'd like to call this new release DbUtils 1.3.  I can imagine someone 
arguing that it should be 2.0, but I don't think so; in DbUtils 1.2 we 
just raised the required JRE version from 1.3 to 1.4 and I think that's 
fine.


The difference between Java 1.4 and 1.5 is much bigger than the difference 
between 1.3 and 1.4, but not so great, I think, that a major version bump 
is required.


If nobody objects, I'll start preparing for a DbUtils 1.3 release in about 
72 hours.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[ANNOUNCEMENT] Commons DbUtils 1.2 released

2009-05-01 Thread Dan Fabulich 

The Commons DbUtils team is pleased to announce the commons-dbutils-1.2 release!

DbUtils is a package of Java utility classes for easing JDBC development.

Source and binary distributions are available for download from the Apache 
Commons download site:


http://commons.apache.org/downloads/download_dbutils.cgi

When downloading, please verify signatures using the KEYS file available 
at the above location when downloading the release.


For more information on Apache Commons DbUtils, visit the Commons DbUtils 
home page:


http://commons.apache.org/dbutils/

Changes in this version include:

Compatibility warnings:

o API change in QueryRunner: the setDataSource method was removed in order
to fix a thread-safety bug (DBUTILS-52)
o We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
o Users who may have extended BeanListHandler.handleRow will find that
this method no longer exists (is no longer called) in DbUtils 1.2
(DBUTILS-37)
o Users who may have extended KeyedHandler will find that its protected
members are now final (to guarantee thread safety). (DBUTILS-51)

Fixed Bugs:
o fillStatement setNull bug with the Postgres/Derby JDBC driver (and others)  Issue: DBUTILS-31. 
o NullPointerException occured at rethrow method  Issue: DBUTILS-40. 
o Add serialVersionUID to BasicRowProcessor.CaseInsensitiveHashMap  Issue: DBUTILS-36.


Changes:
o Removed setDataSource method to guarantee thread safety  Issue: DBUTILS-52. 
o Made numerous private instance members final to guarantee thread safety; changed protected member of KeyedHandler to final  Issue: DBUTILS-51. 
o Support bean property to SQL IN parameter mapping  Issue: DBUTILS-29. 
o Make GenericListHandler (now AbstractListHandler) public  Issue: DBUTILS-33. 
o BasicRowProcessor loses any information on database field case  Issue: DBUTILS-34. 
o BeanListHandler#handle(ResultSet) is not optimal  Issue: DBUTILS-37. 
o Object with Long or Decimal got initial zero value while database field is null  Issue: DBUTILS-42. 
o example documentation page, update query  Issue: DBUTILS-38.


Removed:
o Remove old Maven1/Ant build scripts

Have fun!
-Commons DbUtils team


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: commons-build site

2009-04-29 Thread Dan Fabulich 


Well, there's no pom.xml in there that I can see.  Maven 1.0.2 reports a 
similar error:


xdoc:init:
[echo] Generates the directory structure required for xdocs
Attempting to download qdox-current.jar.
WARNING: Failed to download qdox-current.jar.

BUILD FAILED
File.. C:\Documents and 
Settings\dan.fabulich\.maven\cache\maven-xdoc-plugin-1.9.2\plugin.jelly
Element... attainGoal
Line.. 1006
Column 58
The build cannot continue because of the following unsatisfied dependency:

qdox-current.jar

Total time: 3 seconds
Finished at: Wed Apr 29 22:30:04 PDT 2009

Henri Yandell wrote:


Hang on I'm pretty sure the site is Maven2 based :)

On Wed, Apr 29, 2009 at 10:10 PM, Henri Yandell  wrote:

Go with Maven 1.0.2.

I seem to recall 1.1 not being too great.

On Wed, Apr 29, 2009 at 10:02 PM, Dan Fabulich  wrote:


I've never used m1 before, and am attempting to follow Rahul's directions to
deploy the commons-build site to fix the downlead page for dbutils.

I downloaded maven-1.1 and tried running "maven site:deploy".  It downloaded
a bunch of stuff but then failed with the error below.

Any idea what might be happening to me?

Trying to get missing dependencies (and updated snapshots) required by Maven
Tasklist Plug-in:
- Attempting to download vdoclet:vdoclet:20020711:jar from
http://repo1.maven.org/maven
76K downloaded
- Attempting to download vdoclet:qdox:current:jar from
http://repo1.maven.org/maven
---


Unable to obtain goal [site:deploy]
The build cannot continue because of the following unsatisfied
dependency:


- vdoclet:qdox:current:jar

---
BUILD FAILED
---
Total time   : 1 minutes 4 seconds
Finished at  : Wednesday, April 29, 2009 9:54:56 PM PDT
Final Memory : 5M/10M
---

Rahul Akolkar wrote:


On Tue, Apr 28, 2009 at 2:47 PM, Dan Fabulich  wrote:


I'm so close to releasing DbUtils 1.2 I can taste it!

http://commons.apache.org/downloads/download_dbutils.cgi

This page only shows the 1.1 release, even though 1.2 is available in
archives and on the mirrors.

http://archive.apache.org/dist/commons/dbutils/binaries/

What has to happen to fix the dbutils.cgi page?




Update this:


 http://svn.apache.org/repos/asf/commons/proper/commons-build/trunk/downloads/downloads.xml

Then m1 build and deploy main Commons site (commons-build).

-Rahul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

commons-build site

2009-04-29 Thread Dan Fabulich 


I've never used m1 before, and am attempting to follow Rahul's directions 
to deploy the commons-build site to fix the downlead page for dbutils.


I downloaded maven-1.1 and tried running "maven site:deploy".  It 
downloaded a bunch of stuff but then failed with the error below.


Any idea what might be happening to me?

Trying to get missing dependencies (and updated snapshots) required by Maven 
Tasklist Plug-in:
- Attempting to download vdoclet:vdoclet:20020711:jar from 
http://repo1.maven.org/maven
76K downloaded
- Attempting to download vdoclet:qdox:current:jar from 
http://repo1.maven.org/maven
---

Unable to obtain goal [site:deploy]
The build cannot continue because of the following unsatisfied dependency:

- vdoclet:qdox:current:jar

---
BUILD FAILED
---
Total time   : 1 minutes 4 seconds
Finished at  : Wednesday, April 29, 2009 9:54:56 PM PDT
Final Memory : 5M/10M
---

Rahul Akolkar wrote:


On Tue, Apr 28, 2009 at 2:47 PM, Dan Fabulich  wrote:


I'm so close to releasing DbUtils 1.2 I can taste it!

http://commons.apache.org/downloads/download_dbutils.cgi

This page only shows the 1.1 release, even though 1.2 is available in
archives and on the mirrors.

http://archive.apache.org/dist/commons/dbutils/binaries/

What has to happen to fix the dbutils.cgi page?




Update this:

 
http://svn.apache.org/repos/asf/commons/proper/commons-build/trunk/downloads/downloads.xml

Then m1 build and deploy main Commons site (commons-build).

-Rahul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: download_dbutils

2009-04-29 Thread Dan Fabulich 


Thanks, Rahul...  It appears that I don't have karma to check-in to 
commons-build.  Can someone grant that to me?  (For now, I'll try to 
deploy a site using my working copy.)


Rahul Akolkar wrote:


On Tue, Apr 28, 2009 at 2:47 PM, Dan Fabulich  wrote:


I'm so close to releasing DbUtils 1.2 I can taste it!

http://commons.apache.org/downloads/download_dbutils.cgi

This page only shows the 1.1 release, even though 1.2 is available in
archives and on the mirrors.

http://archive.apache.org/dist/commons/dbutils/binaries/

What has to happen to fix the dbutils.cgi page?




Update this:

 
http://svn.apache.org/repos/asf/commons/proper/commons-build/trunk/downloads/downloads.xml

Then m1 build and deploy main Commons site (commons-build).

-Rahul

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

download_dbutils

2009-04-28 Thread Dan Fabulich 


I'm so close to releasing DbUtils 1.2 I can taste it!

http://commons.apache.org/downloads/download_dbutils.cgi

This page only shows the 1.1 release, even though 1.2 is available in 
archives and on the mirrors.


http://archive.apache.org/dist/commons/dbutils/binaries/

What has to happen to fix the dbutils.cgi page?

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

repo1 mirror time?

2009-04-27 Thread Dan Fabulich 


dbutils shows up here:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/commons-dbutils/commons-dbutils/

But not on central:
http://repo1.maven.org/maven2/commons-dbutils/commons-dbutils/

It's been more than 24 hours now.  Is this cause for concern?

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

site-deploy not configured?

2009-04-25 Thread Dan Fabulich 


I have hit another stumbling block in my neverending quest to release 
DbUtils 1.2.


The wiki here http://wiki.apache.org/commons/CreatingReleases says in step 
"E.3 Deploy the Site" to run "mvn site-deploy", but that doesn't work.


[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Missing site information in the distribution management element in the 
project..
[INFO] 

And this is true.  dbutils/trunk/pom.xml includes a 
 section, but only for the RC profile:


  

  rc
  


  apache.website
  Apache Commons Release Candidate Staging Site
  
${commons.deployment.protocol}://people.apache.org/www/people.apache.org/builds/commons/${commons.componentid}/${commons.release.version}/${commons.rc.version}/site

  

  

https://issues.apache.org/jira/browse/COMMONSSITE-26 has some interesting 
comments and links to other bugs.


Of course, "mvn -Prc site-deploy" works fine, but it just puts the 
deployed site in the builds directory; it doesn't actually deploy the 
site.  There is no configured site for "-Prelease".


What exactly am I supposed to do at this point to get the site deployed? 
I suppose I should manually copy the site from 
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/site ?  To where?


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process

2009-04-22 Thread Dan Fabulich 

OK, so, my new plan is:

cd /www/www.apache.org/dist/commons/dbutils/binaries/
cp 
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*bin*
 .
cd ../source
cp 
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*src*
 .
cd ..
~/svn/apache-committers/tools/releases/symlinks.sh 1.2

Does that sound right to everybady?  (It still has the odd characteristic 
that the new zips and tarballs are named slightly differently from the 
zips and tarballs for 1.1.  It's now called "commons-dbutils-1.2-bin.zip" 
instead of just "commons-dbutils-1.1.zip".)


-Dan

Rahul Akolkar wrote:


On Wed, Apr 22, 2009 at 6:09 PM, Dan Fabulich  wrote:


OK, then here's what I think I want to do:

cd /www/www.apache.org/dist/commons/dbutils
rm *current*



Instead, for the symlinks, look in the committers SVN repo (under
tools/releases) -- theres a symlinks.sh that makes the clobbering you
mention below trivial.

-Rahul



cd binaries
cp
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*bin*
.
cd ../source
cp
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*src*
.

I'm going to give this 72 hours so somebody can -1 it.  Note that the new
zips and tarballs are named slightly differently from the zips and tarballs
for 1.1.  It's now called "commons-dbutils-1.2-bin.zip" instead of just
"commons-dbutils-1.1.zip".

-Dan

sebb wrote:


n 22/04/2009, Dan Fabulich  wrote:


 I'm following the documentation here:
http://wiki.apache.org/commons/CreatingReleases

 At step E.1 it says I'm supposed to "Copy distributions to the Commons
dist/ area".

 Copy what where exactly?  There's a bunch of files here in:

/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2

 But that directory doesn't really look like the destination directory:
 /www/www.apache.org/dist/commons/dbutils/binaries/

 Am I supposed to manually copy -bin and -src archives to the correct
location in dbutils/binaries and dbutils/source?


That's what I do for JMeter, but that does not use Maven, and Commons may
vary.


And clobber the -current
files with the latest version?  (eek?)


I'd prefer not to have the current links; they can easily get out of
date, and the downloaded files have no version indication. They don't
make sense in archive directories.

I don't think the (IMO minor) advantage of having a fixed location for
downloads outweighs the disadvantages.


 -Dan





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Release process

2009-04-22 Thread Dan Fabulich 


OK, then here's what I think I want to do:

cd /www/www.apache.org/dist/commons/dbutils
rm *current*
cd binaries
cp 
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*bin*
 .
cd ../source
cp 
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/*src*
 .

I'm going to give this 72 hours so somebody can -1 it.  Note that the new 
zips and tarballs are named slightly differently from the zips and 
tarballs for 1.1.  It's now called "commons-dbutils-1.2-bin.zip" instead 
of just "commons-dbutils-1.1.zip".


-Dan

sebb wrote:


n 22/04/2009, Dan Fabulich  wrote:


 I'm following the documentation here:
http://wiki.apache.org/commons/CreatingReleases

 At step E.1 it says I'm supposed to "Copy distributions to the Commons
dist/ area".

 Copy what where exactly?  There's a bunch of files here in:
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2

 But that directory doesn't really look like the destination directory:
 /www/www.apache.org/dist/commons/dbutils/binaries/

 Am I supposed to manually copy -bin and -src archives to the correct
location in dbutils/binaries and dbutils/source?


That's what I do for JMeter, but that does not use Maven, and Commons may vary.


And clobber the -current
files with the latest version?  (eek?)


I'd prefer not to have the current links; they can easily get out of
date, and the downloaded files have no version indication. They don't
make sense in archive directories.

I don't think the (IMO minor) advantage of having a fixed location for
downloads outweighs the disadvantages.


 -Dan





-
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Release process

2009-04-22 Thread Dan Fabulich 


I'm following the documentation here: 
http://wiki.apache.org/commons/CreatingReleases


At step E.1 it says I'm supposed to "Copy distributions to the Commons 
dist/ area".


Copy what where exactly?  There's a bunch of files here in:
/www/people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2

But that directory doesn't really look like the destination directory:
/www/www.apache.org/dist/commons/dbutils/binaries/

Am I supposed to manually copy -bin and -src archives to the correct 
location in dbutils/binaries and dbutils/source?  And clobber the -current 
files with the latest version?  (eek?)


-Dan





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[RESULT] [VOTE] Release of DbUtils 1.2 RC3

2009-04-22 Thread Dan Fabulich 
Vote passed, unanimous +1s.  (I just hope I identified roles correctly 
below...)


http://people.apache.org/~jim/projects.html#commons

Joerg Schaible (Commons PMC)
Dan Fabulich (Commons Committer)
Liam Coughlin
Dave Miekle
Henri Yandell (Commons PMC)
Phil Steitz (Commons PMC)

Dan Fabulich wrote:



My third attempt at releasing a commons project; please test rigorously!

RC3 includes an API change to QueryRunner to guarantee thread-safety. 
(DBUTILS-52)


NOTE: No one has yet explicitly said on-list that they have tested DbUtils 
1.2 with a real database.  We should not release it until somebody tries it 
out with a real live Oracle database, as described below.


Compatibility warnings:

* API change in QueryRunner: the setDataSource method was removed in order to 
fix a thread-safety bug (DBUTILS-52)

* We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
* Users who may have extended BeanListHandler.handleRow will find that this 
method no longer exists (is no longer called) in DbUtils 1.2 (DBUTILS-37)
* Users who may have extended KeyedHandler will find that its protected 
members are now final (to guarantee thread safety). (DBUTILS-51)


PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

Although this project has reasonable unit tests, it has no integration tests 
with any actual databases; it is quite possible that the fix for DBUTILS-31 
has broken something on Oracle, MS SQL Server, Derby, or your favorite 
database.


To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g. 
with QueryRunner.update.  Ideally it would be good to verify putting nulls in 
fields of various types: char, varchar, int, boolean, date, etc.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2

Site:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC3

2009-04-16 Thread Dan Fabulich 
We have a +1 from Liam Coughlin, but still need two more binding (PMC) +1s 
to release.


-Dan

Dan Fabulich wrote:

Took me a few weeks, but I finally got around to installing a free instance 
of Oracle (Express Edition 10.2) and testing the null handling code we 
introduced in DbUtils 1.2 (DBUTILS-31).


Sure enough, there's a bug, DBUTILS-55, but I don't think it's very 
important, since it's not a regression; it was there in DbUtils 1.1 and 
nobody appears to have noticed or cared.  :-)  Also, I have no idea how we 
could possibly fix it, since Oracle's JDBC driver doesn't support 
ParameterMetaData.getParameterType.


With that done, and having tested successfully with Apache Derby, I'm now 
prepared to give RC3 my +1.  I believe we also already have a +1 from Joerg 
Schaible, so we still need two more binding +1s to release.


-Dan

Dan Fabulich wrote:



My third attempt at releasing a commons project; please test rigorously!

RC3 includes an API change to QueryRunner to guarantee thread-safety. 
(DBUTILS-52)


NOTE: No one has yet explicitly said on-list that they have tested DbUtils 
1.2 with a real database.  We should not release it until somebody tries it 
out with a real live Oracle database, as described below.


Compatibility warnings:

* API change in QueryRunner: the setDataSource method was removed in order 
to fix a thread-safety bug (DBUTILS-52)

* We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
* Users who may have extended BeanListHandler.handleRow will find that this 
method no longer exists (is no longer called) in DbUtils 1.2 (DBUTILS-37)
* Users who may have extended KeyedHandler will find that its protected 
members are now final (to guarantee thread safety). (DBUTILS-51)


PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

Although this project has reasonable unit tests, it has no integration 
tests with any actual databases; it is quite possible that the fix for 
DBUTILS-31 has broken something on Oracle, MS SQL Server, Derby, or your 
favorite database.


To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g. 
with QueryRunner.update.  Ideally it would be good to verify putting nulls 
in fields of various types: char, varchar, int, boolean, date, etc.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2

Site:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because







-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC3

2009-04-12 Thread Dan Fabulich 
Took me a few weeks, but I finally got around to installing a free 
instance of Oracle (Express Edition 10.2) and testing the null handling 
code we introduced in DbUtils 1.2 (DBUTILS-31).


Sure enough, there's a bug, DBUTILS-55, but I don't think it's very 
important, since it's not a regression; it was there in DbUtils 1.1 and 
nobody appears to have noticed or cared.  :-)  Also, I have no idea how we 
could possibly fix it, since Oracle's JDBC driver doesn't support 
ParameterMetaData.getParameterType.


With that done, and having tested successfully with Apache Derby, I'm now 
prepared to give RC3 my +1.  I believe we also already have a +1 from 
Joerg Schaible, so we still need two more binding +1s to release.


-Dan

Dan Fabulich wrote:



My third attempt at releasing a commons project; please test rigorously!

RC3 includes an API change to QueryRunner to guarantee thread-safety. 
(DBUTILS-52)


NOTE: No one has yet explicitly said on-list that they have tested DbUtils 
1.2 with a real database.  We should not release it until somebody tries it 
out with a real live Oracle database, as described below.


Compatibility warnings:

* API change in QueryRunner: the setDataSource method was removed in order to 
fix a thread-safety bug (DBUTILS-52)

* We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
* Users who may have extended BeanListHandler.handleRow will find that this 
method no longer exists (is no longer called) in DbUtils 1.2 (DBUTILS-37)
* Users who may have extended KeyedHandler will find that its protected 
members are now final (to guarantee thread safety). (DBUTILS-51)


PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

Although this project has reasonable unit tests, it has no integration tests 
with any actual databases; it is quite possible that the fix for DBUTILS-31 
has broken something on Oracle, MS SQL Server, Derby, or your favorite 
database.


To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g. 
with QueryRunner.update.  Ideally it would be good to verify putting nulls in 
fields of various types: char, varchar, int, boolean, date, etc.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2

Site:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC3

2009-03-16 Thread Dan Fabulich 

sebb wrote:


On 15/03/2009, Dan Fabulich  wrote:

 The problem gets even more complicated if we tried to write a generic
"IntegrationTestApp" to work against multiple vendors.  How would the
IntegrationTestApp know what column types are possible?  How would it manage
access to the DataSource in a vendor-agnostic way?  Would we have to add a
dozen (closed source?) DB drivers to our test classpath?


I thought that DBUtils used JDBC, which is a common API?


We still have to call a vendor-specific constructor to cook up a 
DataSource.  (Well, I guess we could just skip the DataSource and use a 
Connection backed by a JDBC URL.)


And then there's the question of column types, though I suppose we could 
make those command-line arguments?  So I guess that leaves us with a test 
app that looks something like:


public class IntegrationTestApp {
  public static void main(String[] args) throws SQLException {
if (args.length < 2) printUsageAndExit();
String url = args[0];
Connection conn = DriverManager.getConnection(url);
QueryRunner runner = new QueryRunner();

runner.update(conn, "DROP TABLE dbutilstest");

StringBuffer sb = new StringBuffer("CREATE TABLE dbutilstest(");
for (int i = 1; i < args.length; i++) {
  if (i != 1) sb.append(", ");
  sb.append("col").append(i).append(' ').append(args[i]);
}
sb.append(')');
runner.update(conn, sb.toString());

sb = new StringBuffer("INSERT INTO dbutilstest VALUES(");
for (int i = 1; i < args.length; i++) {
  if (i != 1) sb.append(", ");
  sb.append('?');
}
sb.append(')');

runner.update(conn, sb.toString(), new Object[args.length-1]);
  }
  private static void printUsageAndExit() {
String className = IntegrationTestApp.class.getCanonicalName();
System.err.println("usage: java " + className
+ "  columnType[...]");
System.err.println("\nexample: java " + className
+ " jdbc:derby:/tmp/myDatabase;create=true varchar char bigint");
System.exit(1);
  }
}

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC3

2009-03-15 Thread Dan Fabulich 

sebb wrote:


Having a ready-made test app might encourage others to test as well.


What do you have in mind here?  An "OracleTestApp" class checked into our 
tests?  Or an "IntegrationTestApp" that would work against multiple 
vendors?


I can certainly imagine an OracleTestApp, but naturally I'm not in a good 
position to write it since I don't actually have Oracle.  (Also, would we 
have to add the Oracle JDBC driver to our POM?)


The problem gets even more complicated if we tried to write a generic 
"IntegrationTestApp" to work against multiple venders.  How would the 
IntegrationTestApp know what column types are possible?  How would it 
manage access to the DataSource in a vendor-agnostic way?  Would we have 
to add a dozen (closed source?) DB drivers to our test classpath?


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC3

2009-03-15 Thread Dan Fabulich 

sebb wrote:


On 15/03/2009, Dan Fabulich  wrote:

 PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

 Although this project has reasonable unit tests, it has no integration
tests with any actual databases; it is quite possible that the fix for
DBUTILS-31 has broken something on Oracle, MS SQL Server, Derby, or your
favorite database.

 To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g.
with QueryRunner.update.  Ideally it would be good to verify putting nulls
in fields of various types: char, varchar, int, boolean, date, etc.


Is there a simple ready-made example I could run?


Not really, partly because I'm not sure I could write one effectively 
without access to an Oracle instance (in which case I'd just run the test 
myself).


I think you'd need to start by creating the table:

http://www.ss64.com/orasyntax/datatypes.html

  CREATE TABLE dbutilstest (
varchar2_column varchar2(50),
nvarchar2_column nvarchar2(50),
varchar_column varchar(50),
char_column char(50),
nchar_column char(50),
number_column number(9),
long_column long,
date_column date,
timestamp_column timestamp,
year_interval_column interval year to month,
day_interval_column interval day to second,
raw_column raw(50),
long_raw_column long_raw(50),
rowid_column rowid,
urowid_column urowid,
clob_column clob,
nclob_column nclob,
blob_column blob,
bfile_column bfile,
xmltype_column xmltype
);

(am I missing any important column types?)

Then you could do something like:

  QueryRunner.update("insert into dbutilstest values(?, ?, ?, ?, ?, ?,"+
+ "?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?", new Object[20]);

I can try to answer further questions if this isn't enough...

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release of DbUtils 1.2 RC3

2009-03-15 Thread Dan Fabulich 


My third attempt at releasing a commons project; please test rigorously!

RC3 includes an API change to QueryRunner to guarantee thread-safety. 
(DBUTILS-52)


NOTE: No one has yet explicitly said on-list that they have tested DbUtils 
1.2 with a real database.  We should not release it until somebody tries 
it out with a real live Oracle database, as described below.


Compatibility warnings:

* API change in QueryRunner: the setDataSource method was removed in order 
to fix a thread-safety bug (DBUTILS-52)

* We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
* Users who may have extended BeanListHandler.handleRow will find that this 
method no longer exists (is no longer called) in DbUtils 1.2 (DBUTILS-37)
* Users who may have extended KeyedHandler will find that its protected members 
are now final (to guarantee thread safety). (DBUTILS-51)


PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

Although this project has reasonable unit tests, it has no integration tests 
with any actual databases; it is quite possible that the fix for DBUTILS-31 has 
broken something on Oracle, MS SQL Server, Derby, or your favorite database.


To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g. with 
QueryRunner.update.  Ideally it would be good to verify putting nulls in fields 
of various types: char, varchar, int, boolean, date, etc.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2

Site:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.2/RC3/staged/commons-dbutils/commons-dbutils/1.2/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC2

2009-03-15 Thread Dan Fabulich 

sebb wrote:


OK, I'd not noticed that the class was usable without the DataSource.

Of course the alternative is to document the class as thread-unsafe...


I would guess that the reason we've never seen a bug filed on this issue 
is that nobody uses setDataSource after the class is created.  For these 
users, QueryRunner is thread-safe.  I think just formalizing that state is 
best.



 I would not attempt to synchronize this class, just leave it unsafe and let
users synchronize.  We should document more explicitly that (unlike some
other classes in DbUtils) it's unsafe.


I'm not sure that the class can be made thread-safe externally.

It's easy enough to override the setters with synchronized versions,
but the getters need to be synchronized as well to ensure that the
data is published correctly. However the class stores the
unsynchronized getters in the Map. So it would be necessary to
override invoke() as well. If this is done, then the whole class has
been overridden - one might as well say it has been rewritten.


I didn't mean that users would synchronize externally by 
extending/overriding, but just by synchronizing access to an instance 
member, or just not sharing them across threads.  *shrug*


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC2

2009-03-11 Thread Dan Fabulich 

sebb wrote:


Sorry, my last e-mail mentioned that QueryRunner was not thread-safe,
but I did not provide a patch.


Dang; I skimmed through other classes looking for unsafe members but 
overlooked your main point.


Or you could change the API further and insist that the DataSource is 
provided at construction time; the variable could be then made final.


This is the right fix.  (In fact, in my haste I thought you'd already done 
it!)  We should change the API as necessary to make the class immutable.



Two of the constructors would need to be removed as well.


No, you could just set the DataSource to "null" in the constructor; its 
Connection-less methods wouldn't work until you created a new object, but 
I think that's fine.


SqlNullCheckedResultSet has many variables that cannot be made final, 
but the Javadoc does not claim it is thread-safe.


It could be made thread-safe by synchronizing (or making volatile) all 
the variables, but this might be too much overhead. Depends whether this 
class is likely to be used from multiple threads or not.


I would not attempt to synchronize this class, just leave it unsafe and 
let users synchronize.  We should document more explicitly that (unlike 
some other classes in DbUtils) it's unsafe.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release of DbUtils 1.2 RC2

2009-03-10 Thread Dan Fabulich 


My second attempt at releasing a commons project; please be gentle. :-)

RC2 includes sebb's patches that make numerous instance variables 
immutable.


NOTE: No one has yet explicitly said on-list that they have tested DbUtils 
1.2 RC1 or RC2 with a real database.  We should not release it until 
somebody tries it out with a real live Oracle database, as described 
below.


Compatibility warnings:

* We upgraded the JVM dependency from JDK 1.3 to JDK 1.4 (DBUTILS-31)
* Users who may have extended BeanListHandler.handleRow will find that 
this method no longer exists (is no longer called) in DbUtils 1.2 
(DBUTILS-37)
* Users who may have extended KeyedHandler will find that its protected 
members are now final (to guarantee thread safety). (DBUTILS-51)


PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

Although this project has reasonable unit tests, it has no integration 
tests with any actual databases; it is quite possible that the fix for 
DBUTILS-31 has broken something on Oracle, MS SQL Server, Derby, or your 
favorite database.


To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g. 
with QueryRunner.update.  Ideally it would be good to verify putting nulls 
in fields of various types: char, varchar, int, boolean, date, etc.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2

Site:

http://people.apache.org/builds/commons/dbutils/1.2/RC2/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.2/RC2/staged/commons-dbutils/commons-dbutils/1.2/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC1

2009-03-10 Thread Dan Fabulich 

sebb wrote:


I think there are some problems with thread-safety.


Yikes!  I didn't investigate very carefully the thread-safety claims of 
these classes (again, not much has changed since 1.1) but I agree with 
your assessment, now that I open my eyes and think about it.


In revision 752369 I incorporated the patches you attached to 
http://issues.apache.org/jira/browse/DBUTILS-51



However, the KeyedHandler instance variables are protected, rather
than private, so making them final would perhaps break some programs.
I don't think the class can be thread-safe at present.


I don't think there's a lot of risk that users required these values to be 
mutable; I would assume that most users just called the super constructor, 
so I applied this patch, too.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC1

2009-03-10 Thread Dan Fabulich 

Jörg Schaible wrote:


However, IBM JDK 6 fails here:

---
Test set: org.apache.commons.dbutils.QueryRunnerTest
---
Tests run: 8, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.341 sec
<<< FAILURE!
testFillStatementWithBeanErrorReadMethodPrivate(org.apache.commons.dbutils.QueryRunnerTest)

It seems that this JDK does more internal checks.


Possibly fixed in trunk revision 752329.  (Fumbled fingers and 
accidentally forgot to add a commit message.)  Please try again in trunk; 
I think it should work.


-Dan
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release of DbUtils 1.2 RC1

2009-03-10 Thread Dan Fabulich 

sebb wrote:


-0.5 because the unit tests seem wrong.


I've incorporated your feedback in revision 752322.  For the record, all 
of those tests predate DbUtils 1.1; we haven't touched them in years.


I think these test changes are pretty minor; not worth an additional RC. 
What do you think?


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DBUTILS] Version numbering

2009-03-08 Thread Dan Fabulich 

Liam Coughlin wrote:


the code NEEDS to change though, and not in a backwards compatible way.  Do
whatever is appropriate with version numbers to indicate that non-binary
compatible changes are coming.


"NEEDS" is a little strong  I think there's room in the world for a 
backwards-compatible dbutils 1.3 with generics and varargs followed 
shortly afterward by a more thoroughly re-worked dbutils 2.0.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

PMC?

2009-03-08 Thread Dan Fabulich 


Who is on the Apache Commons Project Management Committee?  (Google has 
failed me.)


I see this http://commons.apache.org/charter.html but I assume that list 
is out of date...?


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[VOTE] Release of DbUtils 1.2 RC1

2009-03-08 Thread Dan Fabulich 


My first attempt at releasing a commons project; please be gentle. :-)

Compatibility warning: This version is mostly a bugfix release, but to fix 
DBUTILS-31 we had to upgrade the JVM dependency from JDK 1.3 to JDK 1.4. 
Except for that, it is backwards compatible with DbUtils 1.1.


PLEASE TEST THIS RELEASE WITH A REAL DATABASE!

Although this project has reasonable unit tests, it has no integration 
tests with any actual databases; it is quite possible that the fix for 
DBUTILS-31 has broken something on Oracle, MS SQL Server, Derby, or your 
favorite database.


To verify DBUTILS-31, use QueryRunner to put a null value in a field, e.g. 
with QueryRunner.update.  Ideally it would be good to verify putting nulls 
in fields of various types: char, varchar, int, boolean, date, etc.


--

Tag:

https://svn.apache.org/repos/asf/commons/proper/dbutils/tags/DBUTILS_1_2

Site:

http://people.apache.org/builds/commons/dbutils/1.2/RC1/site/index.html

Binaries:

http://people.apache.org/builds/commons/dbutils/1.2/RC1/staged/commons-dbutils/commons-dbutils/1.2/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [DBUTILS] Version numbering (was: Java version not specified in POM)

2009-03-07 Thread Dan Fabulich 

Henri Yandell wrote:


The Java5 version is more up for debate. If the API is no longer
compatible, then we start to lean to 2.0. Especially as calling it 2.0
allows for more of an overhaul of API.


The the API in the "java5" branch is backward compatible; the generics and 
varargs are erased at compile time.  Of course, the code has to be 
compiled with target=1.5, but on a Java 1.5 VM you could swap it in and 
not notice the difference.


If that lets us call it "dbutils 1.3" and avoid extra branching work, 
that'd be great.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[DBUTILS] Version numbering (was: Java version not specified in POM)

2009-03-07 Thread Dan Fabulich 

Good catch.  :-(

Uh, if dbutils 1.1 was compatible with java 1.3, and we want to depend on 
java 1.4 in the next version, do we have to call it "dbutils 2.0"?


I assume not; I think we can still call it "dbutils 1.2" even though we 
depend on java 1.4 now.  Is that OK?


Similarly, could/should we call the java5 version "1.3"?  That would 
certainly save time on branch management...?


sebb wrote:


The pom.xml does not specify a java source or target version, so
defaults to 1.3 (from the parent pom)

As far as I can tell, the component requires at least 1.4 so the POM
needs to be updated.

[IMO the compiler settings should never be delegated to the parent POM]



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Creating a commons release

2009-03-06 Thread Dan Fabulich 


Thanks, got that sorted.  Now I have a new question.

I've got a gpg key; I checked the public key into 
https://svn.apache.org/repos/asf/commons/trunks-proper/KEYS

in revision 751205.

The KEYS file header says I'm supposed to scp it to 
people.apache.org:/www/www.apache.org/dist/commons


I don't have permission to write to that file.  It's group-writeable, and 
the group is "commons".  Apparently my user ("dfabulich") on 
people.apache.org is not yet a member of the commons group?


Other than that, I think I'm ready to stage dbutils 1.2 RC1.  If anyone 
sees an obvious problem now, please let me know.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Creating a commons release

2009-03-06 Thread Dan Fabulich 


I'm reading the documentation here (is this the most up-to-date?)
http://wiki.apache.org/commons/CreatingReleases

It says to make sure my changes.xml has been updated.  I've done a number 
of Maven releases before, though not in commons, and I'm not familiar with 
that particular file.  Where do I get one?  How do I update it?


Also...

How do I run a RAT report in commons?  Is it being run for me by gump?  If 
so, where is its output?


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] bugfixing/java5 branches ready for merge

2009-02-25 Thread Dan Fabulich 

Liam Coughlin wrote:


DBUTILS-49QueryRunner - fillStatement method does not work for
PostgreSQL database drivers
I'm pretty sure this is addressed with the fill change to use the
parametermetadata.


Yes, this bug is yet another dupe of DBUTILS-44 and friends.  I think it's 
fixed in 742865...  This bug was heavily duplicated, not surprising that I 
missed a copy.



DBUTILS-48 Maintaining a parallel Java 1.5 version of
DButils
You folks are covering this with the different branch configs post buf fix.


+1, close it.


DBUTILS-47 Add a StatementFiller to be able to provide a Bean for
updates, instead of bean
values.
I'm pretty sure this is outside the scope of dbutils, and would be covered
by things users of the library add
to it's extensible framework.

DBUTILS-43 an helper set of classes for JDBC processing with prepared
statement 
This is not trivial -- tackle it now, or tackle it later?


I see DBUTILS-47 and DBUTILS-43 as dupes of DBUTILS-29, fixed in 742870 
(and tweaked in later revisions).  They all just want to have some way of 
using a bean or Object[] to manage a PreparedStatement, IMO.



DBUTILS-30 [dbutils] New ResultSetHandler -
ObjectHandler
I'm pretty sure this is outside the scope of dbutils, and would be covered
by things users of the library add
to it's extensible framework.


Indeed, I felt the best way to handle this was to use 
BeanUtils.copyProperties.  We should just close this bug out.



DBUTILS-28 [dbutils] Stored Procedure Runner and Bean Reuse Handler code
submission 
This is sort of a weird double issue that rolls up DBUTILS-43 and
DBUTILS-30.

I think you probably want to defer any work with stored procedures for a
little while because there's just more interesting and important things to
work on.


DBUTILS-28 is a half-dupe of DBUTILS-30, but stored procedures 
(CallableStatement) is its own ball of wax not covered by DBUTILS-43 
(which covers only PreparedStatements, a supertype of CallableStatement).


Regardless, I don't think we should include Kyle's patch; we should close 
out DBUTILS-28, in favor of DBUTILS-50 which I just filed.  DBUTILS-50 
should be done someday.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] bugfixing/java5 branches ready for merge

2009-02-24 Thread Dan Fabulich 

Henri Yandell wrote:


742870 - ?? - Lacking Unit Tests, not liking the catch Exception.
RuntimeException throwing needs String arg. Generally not trusting the
Java API here to work beautifully and wanting to have covered a bunch
of use cases.


Thanks for reviewing!

I tweaked exception handling and added unit tests in bugfixing branch 
revision 747449.  As I wrote the unit tests I manuallly looked at the 
exception stacktraces and verified that they provided useful error 
messages to the user. 
http://svn.apache.org/viewvc?view=rev&revision=747449


I also merged those changes to java5 branch revision 747452.


So apart from the one commit, I'm +1 on the changes on the bugfixes branch.


In that case, I think we're ready to contemplate executing the plan I'd 
identified earlier:



If I were a commons/dbutils committer right now, I think I'd probably do
these things (all of which require committer karma):

1) Merge "bugfixing" back to trunk
2) Close out all of the bugs I fixed
3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
4) Make a dbutils/1.x branch
5) Merge "java5" back to trunk
6) Stage/vote on a dbutils-2.0 release based on java5/trunk


How do we want to begin work on this?  Henri, do you want to these steps? 
Alternately, I can do them myself if I get the karma to do so...?


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[dbutils] bugfixing/java5 branches ready for merge

2009-02-11 Thread Dan Fabulich 


I've fixed a bunch of bugs in the bugfixing branch.  I think I've fixed 
all except bug DBUTILS-30/-28 (they're dupes).


https://svn.apache.org/repos/asf/commons/sandbox/dbutils/bugfixing
http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/
http://svn.apache.org/viewvc/commons/sandbox/dbutils/bugfixing/?view=log

I've also done a bunch of java5-izing (generics/varargs) in the java5 
branch, and merged in the bug fixes from the bugfixing branch.


https://svn.apache.org/repos/asf/commons/sandbox/dbutils/java5
http://svn.apache.org/viewvc/commons/sandbox/dbutils/java5/

The java5 branch is meant to be exactly like the bugfixing branch, except 
with generics and varargs.  The generics and varargs should be erased at 
compile time, so the runtime API should be indistinguishable from the 
runtime API of dbutils-1.2.


Review/comments welcome.

If I were a commons/dbutils committer right now, I think I'd probably do 
these things (all of which require committer karma):


1) Merge "bugfixing" back to trunk
2) Close out all of the bugs I fixed
3) Stage/vote on a dbutils-1.2 release based on bugfixing/trunk
4) Make a dbutils/1.x branch
5) Merge "java5" back to trunk
6) Stage/vote on a dbutils-2.0 release based on java5/trunk

... and then start working on crazy API refactorings like my interface 
bean idea and Liam's RowHolder suggestions, in preparation for a 3.0 
release or something.


However, I am not, in fact, a commons/dbutils committer, so somewhere in 
there it might be nice to have a vote about that. ;-)


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[beanutils] [dbutils] Interfaces as beans, for databases

2009-02-10 Thread Dan Fabulich 


Have you seen ActiveObjects?  It's an incubating ORM layer over at 
dev.java.net; it's got some neat stuff in it.


https://activeobjects.dev.java.net/basic-concepts.html

I'm especially drawn to the idea that a bean could be defined as an 
interface, rather than as a concrete implementation.  It saves me from 
having to actually define the implementation of getters and setters, while 
still preserving type-safety (and auto-completion in my IDE).


  interface Employee {
public String getName();
public void setName(String name);
  }

It's easy to use java.lang.reflect.Proxy to automatically generate simple 
implementations for bean-like interfaces.  The InvocationHandler could 
just keep a DynaBean internally that maps properties to values; when a 
getter is called, we'd just call an appropriate getter on the DynaBean; 
when a setter is called, we'd just call an appropriate setter on the 
DynaBean.


  Employee e = instantiateBeanInterface(Employee.class);

The result would be something like a type-safe DynaBean, which intrigues 
me.


We could go even further.  Perhaps if the interface bean (IBean?) 
implemented other tagging interfaces, we could add in additional 
functionality.


For example, BeanUtils could define an interface like this:

  interface DirtyManagedBean {
public PropertyDescriptor[] dirtyProperties();
public boolean isDirty(String propertyName);
public void clean(String propertyName);
public void cleanAll();
  }

Then, I could make my Employee interface implement DirtyManaged, and have 
the automatically generated bean keep track of which properties were dirty 
(had been modified) and which were clean.


We could also have an interface like this:

  interface SupportsPropertyChange {
public java.beans.PropertyChangeSupport propertyChangeSupport();
  }

If my Employee implemented SupportsPropertyChange, I could retrieve its 
associated PropertyChangeSupport object and attach change listeners; we'd 
guarantee that the generated bean would fire change events via the support 
object.


FOR DATABASES

Specifically, I'm imagining IBeans would be helpful in the world of SQL 
databases, outside of any ORM layer.


1) You could automatically INSERT/UPDATE a DirtyManaged bean, adding only 
explicitly dirty columns to the SQL statement.


2) In general, an IBean could wrap around a PreparedStatement:

  PreparedStatement ps = prepareStatement();
  Employee e = proxyPreparedStatement(Employee.class, ps, columnList);
  employee.setFirstName("Dan");
  employee.setLastName("Fabulich");
  ps.addBatch();
  employee.setFirstName("Somebody");
  employee.setLastName("Else");
  ps.addBatch();
  ps.executeBatch();

3) An IBean could wrap around a ResultSet; when you call .next() on the 
result set, the IBeans getters/setters could return the new values, 
eliminating the need to create N objects for N rows.


  Employee employee = proxyResultSet(Employee.class, resultSet);
  while (resultSet.next()) {
System.out.println("Name: " + employee.getName());
System.out.println("Address: " + employee.getAddress());
  }

3) If you're doing a join, you could define a new bean that wrapped around 
the joined query via multiple inheritance.


  interface EmployeeAddressQuery implements Employee, Address;

  Statement s = c.createStatement("SELECT * from employees, addresses");
  resultSet = s.executeQuery();
  Employee employee = proxyResultSet(Employee.class, resultSet);
  while (resultSet.next()) {
System.out.println("Name: " + employee.getName());
System.out.println("Street Name: " + employee.getStreet());
  }

Thoughts?

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] Questions about a few of bugs

2009-02-10 Thread Dan Fabulich 

Liam Coughlin wrote:


On Tue, Feb 10, 2009 at 2:32 AM, Dan Fabulich  wrote:


1) OptimalBeanListHandler


Ideally, these classes should be split up more.  There shouldn't really be a
BeanListHandler, just a ListHandler which takes a RowHandler on
construction, and then you can just use the appropriate BeanRowHandler or
OptimizedBeanRowHandler or some other custom row handler to map how you like
which would resolve the whole issue.


Ah, but the whole point of this enhancement is that it's unperformant to 
use RowProcessor#toBean on each row; it's much faster to call 
RowProcessor#toBeanList once.  So there's no such thing as an 
OptimizedBeanRowHandler; the optimization is to not use a RowHandler!



3) CaseInsensitiveMap
http://issues.apache.org/jira/browse/DBUTILS-34

Two distinct users claim to want CIM to return the keys in their ORIGINAL
case (i.e. not lowercased).  Why would anyone need this?  I don't get it.



Given the amount of reflection and property referencing that occurs in java
apps these days, i can think of a million reasons why a CIM should return
the keys in original case.  There shouldn't be any particular performance
implication here, just a little bit of extra memory and housekeeping.


Well, here's my thinking:
1) We don't provide a public CaseInsensitiveMap in our API.  The CIM is a 
purely private object used in the guts of BasicRowProcessor.


This is why I don't understand the point of the bug...  Why would anyone 
care how this internal object is implemented, so long as BasicRowProcessor 
works?


2) Extra housekeeping = slower performance

3) The biggest risk here is accidentally introducing thread-safety 
problems.  The patch applied to DBUTILS-34 is not thread-safe (I think?) 
because it keeps two internal data structures (the "real" map and the 
"lowerCaseMap") that can fall out-of-sync, corrupting the map.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[dbutils] Questions about a few of bugs

2009-02-09 Thread Dan Fabulich 


I had some questions about a few remaining bugs... maybe somebody here can 
help...


1) OptimalBeanListHandler

http://issues.apache.org/jira/browse/DBUTILS-37
This bug provides a patch that considerably improves the performance of 
BeanListHandler.


However, Julien correctly points out that:
With the change I propose, the BeanListHandler#handleRow(ResultSet) 
method is never called anymore. So, any subclass of BeanListHandler 
which would override this method would not work properly anymore.


Julien's patch creates a separate "OptimalBeanListHandler" ... but that 
really shouldn't be necessary, right?


We should be able to just replace the existing BLH with this fast one 
without worrying about users who may have extended BLH#handleRow, I'd 
think... At the very least I think nobody should use the old slow one by 
accident.


2) Inflate existing object
http://issues.apache.org/jira/browse/DBUTILS-28

I'm a little skeptical of the patch for this bug.  Is this issue 
important?  (It has 0 votes and 0 watchers, so I think not.)


3) CaseInsensitiveMap
http://issues.apache.org/jira/browse/DBUTILS-34

Two distinct users claim to want CIM to return the keys in their ORIGINAL 
case (i.e. not lowercased).  Why would anyone need this?  I don't get it.


-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] QueryRunner.fillStatement and the null problem (long)

2009-02-09 Thread Dan Fabulich 


OK, I've checked in a fix for the null problem (and the five bugs 
surrounding it) in revision 742865.  Code review here is welcome.


http://svn.apache.org/viewvc?view=rev&revision=742865

The code passes against Derby, but, as I mentioned earlier, I don't have 
an Oracle test instance to run against, so if some interested party were 
interested in pulling down the code to try it, I'd much appreciate the 
help.


Thanks again!

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [dbutils] QueryRunner.fillStatement and the null problem (long)

2009-02-09 Thread Dan Fabulich 

Liam Coughlin wrote:


b) Yes it will have a thread safety issue -- you'll need to synchronize on
something when setting the pmdKnownBroken variable.


When setting?  Or when reading?  Remember, once pmdKnownBroken is true, it 
will never again be false, so there's no risk that one thread will try to 
set it to true and another thread will try to set it to false.


IMO the biggest risks here are:

1) Running getParameterType too many times (ideally we should only ever 
run it once on Oracle, but that may be too much to ask)


2) We overcompensate and create an unecessary synchronization bottleneck

What if I just make pmdKnownBroken "volatile"?

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[dbutils] QueryRunner.fillStatement and the null problem (long)

2009-02-09 Thread Dan Fabulich 


This email is long, so here's the executive summary:

Summary: The Oracle JDBC driver is broken in ways that will require some 
Oracle-specific workarounds.  I think I have a good workaround in mind, 
but I don't actually have an Oracle instance available to test.  Can 
somebody tell me if I'm doing something stupid here?


INTRO

QueryRunner has a nice helper method, "fillStatement(PreparedStatement 
stmt, Object[] params)".  It helps you turn calls like this:


  stmt.setString(1, "foo");
  stmt.setInteger(2, 42);
  stmt.setDate(3, myDate);

into calls like this:

  qr.fillStatement(stmt, new Object[] { "foo", new Integer(42), myDate});

In the new "java5" branch, we can use varargs and auto-boxing to make it 
even nicer:


  qr.fillStatement(stmt, "foo", 42, myDate);

Pretty cool, huh?  But it has a problem when you try to pass in a null 
parameter in the object array.


THE PROBLEM WITH NULLS (ORACLE SUCKS)

Under the hood, fillStatement actually does this:

  stmt.setObject(1, "foo");
  stmt.setObject(2, 42);
  stmt.setObject(3, myDate);

But this doesn't work on some databases, including Oracle, when using a 
null parameter.


The Sun documentation says:
http://java.sun.com/javase/6/docs/api/java/sql/PreparedStatement.html#setObject(int,%20java.lang.Object)
Note: Not all databases allow for a non-typed Null to be sent to the 
backend. For maximum portability, the setNull or the setObject(int 
parameterIndex, Object x, int sqlType) method should be used instead of 
setObject(int parameterIndex, Object x).


That is, you're supposed to pass in a sqlType integer, matching one of the 
defined constants in java.sql.Types.  Types.NULL is a legal constant, but 
it doesn't work with Oracle drivers.


dgraham tried to fix this, using code like this:
http://svn.apache.org/viewvc?view=rev&revision=141728

for (int i = 0; i < params.length; i++) {
if (params[i] != null) {
stmt.setObject(i + 1, params[i]);
} else {
// VARCHAR works with many drivers regardless
// of the actual column type.  Oddly, NULL and
// OTHER don't work with Oracle's drivers.
stmt.setNull(i + 1, Types.VARCHAR);
}
}

It may well work with "many drivers," but unfortunately it doesn't work 
with PostgreSQL. :-( http://issues.apache.org/jira/browse/DBUTILS-39


Here's a few proposed solutions to this problem:
http://issues.apache.org/jira/browse/DBUTILS-14
http://issues.apache.org/jira/browse/DBUTILS-31
http://issues.apache.org/jira/browse/DBUTILS-41
http://issues.apache.org/jira/browse/DBUTILS-44


PARAMETER META DATA WON'T WORK (ORACLE SUCKS)

DBUTILS-31 suggests an ideal workaround for this problem.  In JDBC 3.0 
(Java 1.4) compliant drivers, you can just ask the PreparedStament what 
the SQL type of any given column is, using the getParameterMetaData() 
statement, like this:


for (int i = 0; i < params.length; i++) {
if (params[i] != null) {
stmt.setObject(i + 1, params[i]);
} else {
int sqlType = stmt.getParameterMetaData().getParameterType(i+1);
stmt.setNull(i + 1, sqlType);
}
}

This looks like a pretty good solution to me!  Easy as pie!  But 
unfortunately, it won't work on Oracle!

http://forums.oracle.com/forums/thread.jspa?threadID=585880

You have to register to read that link (it's free but it's a hassle). But 
the most recent post is confirming that it's still broken in Oct 2008. If 
you call getParameterType, you get error ORA-17023 "Unsupported feature." 
Lame!


MY PROPOSED SOLUTION

Francis Townsend replied to DBUTILS-31, suggesting:
Unfortunately, it does not look as if there is no method that can 
determine this before calling the getParameterType method. Which means 
we would need to catch the exception and role back to the previous code, 
namely use the VARCHAR type when setting null. This would always be 
thrown by the Oracle driver, severely slowing it down.


That would maybe look something like this:

for (int i = 0; i < params.length; i++) {
if (params[i] != null) {
stmt.setObject(i + 1, params[i]);
} else {
int sqlType = Types.VARCHAR;
try {
sqlType = stmt.getParameterMetaData().getParameterType(i+1);
} catch (Exception e) {}
stmt.setNull(i + 1, sqlType);
}
}

... but that would indeed severely impact Oracle performance.

I think the fix in that case would be to cache the result:

int sqlType = Types.VARCHAR;
if (!pmdKnownBroken) {
try {
sqlType = stmt.getParameterMetaData().getParameterType(i+1);
} catch (Exception e) { pmdKnownBroken = true; }
}
stmt.setNull(i + 1, sqlType);

Possibly we'd add a new argument to the QueryRunner constructor, allowing 
you to set pmdKnownBroken to true right away.


OPEN QUESTIONS

1) Will caching this result work?  Will it impact thread-safety in some 
negative way?


2) How

[dbutils] sandbox "java5" branch and "bugfixing" branch created

2009-02-07 Thread Dan Fabulich 

Henri Yandell wrote:


Let's create a branch in the sandbox and let Dan dive in. Effectively
it's the git model, but slightly closer because he's already a
committer. Once it's reached its release point, we can all be looking
and debating whether it is DbUtils 2.0 or DbUtils2.

[The first is a new release of the existing component, the second is,
akin to how CLI2 should have been done, a new product]


I wound up creating two branches: a "java5" branch and a "bugfixing" 
branch.  The idea of the "bugfixing" branch is that it should be totally 
uncontroversial to roll into trunk and release as dbutils 1.2.


In revision 741990 I've checked in my initial round of Java 5 patching in 
in https://svn.apache.org/repos/asf/commons/sandbox/dbutils/java5 ... feel 
free to review.


For the record, my goal in the java5 branch is NOT to meaningfully modify 
the API.  In fact, I think my java5 changes have made no change to the 
runtime API at all; a jar compiled against DbUtils trunk should continue 
to work if you use a Java5 VM and swap in my java5 jar.


I think there should be no need to create a "DbUtils2" project for this; 
calling it "2.0" seems more appropriate.


I haven't checked anything into 
https://svn.apache.org/repos/asf/commons/sandbox/dbutils/bugfixing yet, 
but I will.


Thanks again!

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[dbutils] karma Re: Request sandbox access

2009-02-06 Thread Dan Fabulich 

Rahul Akolkar wrote:


Help is usually quite welcome, the sandbox is open to all Apache
committers. Ofcourse, [dbutils] isn't in the sandbox -- though you
should be able to start a JDK 1.5 branch in the sandbox if you want.


Do you mean that, as an Apache committer, I already have sandbox karma? 
That doesn't appear to be true at the moment.


C:\svn\dbutils >svn mkdir https://svn.apache.org/repos/asf/commons/sandbox/dbutils 
--username dfabulich -m "Preparation for java5 branch"
svn: Server sent unexpected return value (403 Forbidden) in response to 
CHECKOUT request for '/repos/asf/!svn/ver/741845/commons/sandbox'

Assuming I don't yet have karma to write to the sandbox, may I politely 
ask someone to grant it to me?


Thanks!

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Request sandbox access

2009-02-05 Thread Dan Fabulich 


I just submitted a big patch to DbUtils to update the API to use Java 5 
features (generics, varargs).


http://issues.apache.org/jira/browse/DBUTILS-48

There really aren't very many bugs left in this project; almost all of 
them have patches attached.  I think it wouldn't be much work for somebody 
(I'm volunteering) to close them all out and release DbUtils 1.2.


All I'd need is the right to close bugs in JIRA and some check-in rights; 
even sandbox access would be fine (I'm a registered Apache committer).


May I volunteer?

-Dan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org