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
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
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
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
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
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
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
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.
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:
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
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
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.
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
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
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
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
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.
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
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:
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
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
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
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]
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
.
-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
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
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
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
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
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.
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
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
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
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
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?
Jörg Schaible wrote:
However, IBM JDK 6 fails here:
---
Test set: org.apache.commons.dbutils.QueryRunnerTest
---
Tests run: 8, Failures: 0,
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
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
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
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:
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
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
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
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
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
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
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.
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?
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
49 matches
Mail list logo
