Updating dbutils download page
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
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 d...@fabulich.com Reply-To: Commons Developers List dev@commons.apache.org To: Commons Developers List dev@commons.apache.org 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
[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
Re: [VOTE] Release of DbUtils 1.3 RC3
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
Re: [VOTE] Release of DbUtils 1.3 RC2
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
[VOTE] Release of DbUtils 1.3 RC3
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: [dbutils] binary compatibility
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?
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] Ping for next release ?
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
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.
) {
// 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.
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: [releasing] SVN Tag creeated by maven
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: [releasing] SVN Tag creeated by maven
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: AW: [releasing] SVN Tag creeated by maven
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: AW: AW: [releasing] SVN Tag creeated by maven
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: [releasing] SVN Tag creeated by maven
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
Henri just ran the build for me. :-( Rahul Akolkar wrote: On Thu, Apr 30, 2009 at 1:30 AM, Dan Fabulich d...@fabulich.com wrote: Well, there's no pom.xml in there that I can see. Maven 1.0.2 reports a similar error: snip/ 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
[ANNOUNCEMENT] Commons DbUtils 1.2 released
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
[dbutils] Version number for next release
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
Re: commons-build site
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 flame...@gmail.com 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 d...@fabulich.com 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 d...@fabulich.com 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? snip/ 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
repo1 mirror time?
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?
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
distributionManagement section, but only for the RC profile:
profiles
profile
idrc/id
distributionManagement
!-- Cannot define in parent ATM, see COMMONSSITE-26 --
site
idapache.website/id
nameApache Commons Release Candidate Staging Site/name
url${commons.deployment.protocol}://people.apache.org/www/people.apache.org/builds/commons/${commons.componentid}/${commons.release.version}/${commons.rc.version}/site/url
/site
/distributionManagement
/profile
/profiles
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
[RESULT] [VOTE] Release of DbUtils 1.2 RC3
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: Release process
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 d...@fabulich.com 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
Re: Release process
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 d...@fabulich.com wrote: OK, then here's what I think I want to do: cd /www/www.apache.org/dist/commons/dbutils rm *current* snip/ 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 d...@fabulich.com 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: [VOTE] Release of DbUtils 1.2 RC3
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
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
sebb wrote:
On 15/03/2009, Dan Fabulich d...@fabulich.com 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
+ jdbcUrl 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 RC2
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
[VOTE] Release of DbUtils 1.2 RC3
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
sebb wrote: On 15/03/2009, Dan Fabulich d...@fabulich.com 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
Re: [VOTE] Release of DbUtils 1.2 RC3
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 RC2
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
Re: [VOTE] Release of DbUtils 1.2 RC1
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: [VOTE] Release of DbUtils 1.2 RC1
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
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
[VOTE] Release of DbUtils 1.2 RC2
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
[VOTE] Release of DbUtils 1.2 RC1
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
PMC?
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
Re: [DBUTILS] Version numbering
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
[DBUTILS] Version numbering (was: Java version not specified in POM)
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: [DBUTILS] Version numbering (was: Java version not specified in POM)
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
Creating a commons release
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: Creating a commons release
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
Re: [dbutils] bugfixing/java5 branches ready for merge
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=revrevision=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
[beanutils] [dbutils] Interfaces as beans, for databases
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
[dbutils] karma Re: Request sandbox access
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
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
