Re: [LANG][GUMP] Take current Lang changes out of main Gump?
On 2009-03-16, Henri Yandell wrote: > Personally I think failing is good and we'll learn lots from it. I'd > like to keep trunk until the consumer community indicate it's a pain > point. Right now it doesn't look as if any of the projects with many dependees was affected. So the changes right now don't seem to hurt to many unrelated projects. If a project isn't willing to adapt to the commons-lang changes, I'll add a project for the 2.4 tag and make this project depend on it, OK? > For example making a lang-backcompat jar for enum and exceptions > might be a better choice and getting projects to add a dependency on > that in gump. This works great for Ant built projects but doesn't work at all for Maven built ones since those additional jars would never be used by Maven unless they are listed in the POM. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] 2.0 release
On Mar 16, 2009, at 5:32 PM, sebb wrote: On 16/03/2009, Ralph Goers wrote: On Mar 16, 2009, at 3:31 PM, Jörg Schaible wrote: Hi Ralph, Ralph Goers wrote: I have finished the work to implement webdav versioning support in VFS trunk. I would like to take advantage of this in Commons Configuration (that code is also complete) but to do so I need a release of VFS 2.0. What must be done to accomplish this? FWIW I don't yet have a PGP key so I kind of get stuck at that spot in the "creating releases" instructions. I'd like to fix VFS-169 first. I have a complete different approach than Frank. If you don't mind, I'll commit it directly as soon as possible. That's fine. Also, while you do this you might want to review the project and make sure it has everything for a proper release. I will be doing the same? There seem to be a few java files that don't have AL headers. The source of these needs to be established and the AL header added if OK. Thanks, I'll take a look. Also, which Java version is targettted? The pom files don't seem to include a definition. They are inherited from the commons parent pom. Actually, just found that project.properties species source/ target=1.3. It would be helpful to include this in the Maven2 POM(s). project.properties don't apply. They are left over from the maven 1 build. That should really be deleted along with the project.xml However, there is some Java 1.4+ code in core/ and sandbox/ as several files use RuntimeException(Throwable). Hmm. I thought it was targeted at 1.3 but I wonder how that could be. In fact, a grep on vfs-1-trunk shows it was also doing that. Given that, I would say that changing it to 1.4 would be the correct thing to do. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] 2.0 release
On 16/03/2009, Ralph Goers wrote: > > On Mar 16, 2009, at 3:31 PM, Jörg Schaible wrote: > > > > Hi Ralph, > > > > Ralph Goers wrote: > > > > > > > I have finished the work to implement webdav versioning support in VFS > > > trunk. I would like to take advantage of this in Commons Configuration > > > (that code is also complete) but to do so I need a release of VFS 2.0. > > > What must be done to accomplish this? FWIW I don't yet have a PGP key > > > so I kind of get stuck at that spot in the "creating releases" > > > instructions. > > > > > > > I'd like to fix VFS-169 first. I have a complete different approach than > > Frank. If you don't mind, I'll commit it directly as soon as possible. > > > > > > That's fine. Also, while you do this you might want to review the project > and make sure it has everything for a proper release. I will be doing the > same? There seem to be a few java files that don't have AL headers. The source of these needs to be established and the AL header added if OK. Also, which Java version is targettted? The pom files don't seem to include a definition. Actually, just found that project.properties species source/target=1.3. It would be helpful to include this in the Maven2 POM(s). However, there is some Java 1.4+ code in core/ and sandbox/ as several files use RuntimeException(Throwable). > Also, is there a way to release a SNAPSHOT so that I can commit my Commons > Configuration enhancements? > > Ralph > > - > 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: [VFS] 2.0 release
On Mar 16, 2009, at 3:31 PM, Jörg Schaible wrote: Hi Ralph, Ralph Goers wrote: I have finished the work to implement webdav versioning support in VFS trunk. I would like to take advantage of this in Commons Configuration (that code is also complete) but to do so I need a release of VFS 2.0. What must be done to accomplish this? FWIW I don't yet have a PGP key so I kind of get stuck at that spot in the "creating releases" instructions. I'd like to fix VFS-169 first. I have a complete different approach than Frank. If you don't mind, I'll commit it directly as soon as possible. That's fine. Also, while you do this you might want to review the project and make sure it has everything for a proper release. I will be doing the same? Also, is there a way to release a SNAPSHOT so that I can commit my Commons Configuration enhancements? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release commons-exec-1.0 based on RC5
Gary Gregory wrote: > Siegfried: > > If you've gone through the pains of running builds through your JDK 'zoo', > you might want to list what you've tested here for the record. - Blackdown JDK 1.4.2.03 [blackdown-jdk-1.4.2] - IBM JDK 1.4.2.12 [ibm-jdk-bin-1.4] - IBM JDK 1.5.0.9 [ibm-jdk-bin-1.5] - IBM JDK 1.6.0.3 [ibm-jdk-bin-1.6] - IcedTea6-bin 1.4 [icedtea6-bin] - WebLogic JRockit 1.4.2.16 [jrockit-jdk-bin-1.4] - WebLogic JRockit 1.5.0.14 [jrockit-jdk-bin-1.5] - Sun JDK 1.4.2.19 [sun-jdk-1.4] - Sun JDK 1.5.0.17 [sun-jdk-1.5] - Sun JDK 1.6.0.12 [sun-jdk-1.6] IBM JDK 1.4 + 1.5 fail as usual due to problems with Maven itself. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release commons-exec-1.0 based on RC5
Siegfried: If you've gone through the pains of running builds through your JDK 'zoo', you might want to list what you've tested here for the record. Gary > -Original Message- > From: news [mailto:n...@ger.gmane.org] On Behalf Of Jörg Schaible > Sent: Monday, March 16, 2009 3:56 PM > To: dev@commons.apache.org > Subject: Re: [VOTE] Release commons-exec-1.0 based on RC5 > > +1, tests succeed on my compiler zoo. > > Siegfried Goeschl wrote: > > > Hi folks, > > > > here is the next release candidate for commons-exec-1.0 > > > > +) the findbugs configuration file is now part of the source > > distribution so the site can be rebuild based on the source distribution > > alone > > +) using version number "1.0" instead of "1.0.0" > > +) I failed to create an extended manifest for sources and javadoc jars > > (not really important and a parent pom issue) > > > > Cheers, > > > > Siegfried Goeschl > > > > --- > > > > Tag: > > > > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0 > > > > Site: > > > > http://people.apache.org/builds/commons/exec/1.0/RC5/site/index.html > > > > Binaries: > > > > > http://people.apache.org/builds/commons/exec/1.0/RC5/staged/org/apache/com > mons/commons-exec/1.0/ > > > > [ ] +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 commons-exec-1.0 based on RC5
+1, tests succeed on my compiler zoo. Siegfried Goeschl wrote: > Hi folks, > > here is the next release candidate for commons-exec-1.0 > > +) the findbugs configuration file is now part of the source > distribution so the site can be rebuild based on the source distribution > alone > +) using version number "1.0" instead of "1.0.0" > +) I failed to create an extended manifest for sources and javadoc jars > (not really important and a parent pom issue) > > Cheers, > > Siegfried Goeschl > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0 > > Site: > > http://people.apache.org/builds/commons/exec/1.0/RC5/site/index.html > > Binaries: > > http://people.apache.org/builds/commons/exec/1.0/RC5/staged/org/apache/commons/commons-exec/1.0/ > > [ ] +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: [VFS] 2.0 release
Hi Ralph, Ralph Goers wrote: > I have finished the work to implement webdav versioning support in VFS > trunk. I would like to take advantage of this in Commons Configuration > (that code is also complete) but to do so I need a release of VFS 2.0. > What must be done to accomplish this? FWIW I don't yet have a PGP key > so I kind of get stuck at that spot in the "creating releases" > instructions. I'd like to fix VFS-169 first. I have a complete different approach than Frank. If you don't mind, I'll commit it directly as soon as possible. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] 2.0 release
It's not necessary to get the key signed by others before using it to sign a release. Just create a key and add it to KEYS and upload it to a key server. On 16/03/2009, Ralph Goers wrote: > I'd be happy to do all that. But my understanding is that I can't do the > release until all those steps are completed. I'd really like VFS 2.0 > released asap. Since I'm also not on the PMC I can't even vote for the > release. As far as I can tell I'm the only one committing code but I know > I'm not the only one using VFS. > > Ralph > > > On Mar 16, 2009, at 10:05 AM, Siegfried Goeschl wrote: > > > > Hi Ralph, > > > > +) see http://www.apache.org/dev/release-signing.html > > +) you can upload your key to a public key server even if it is not > > trusted yet > > +) afterwards you add it to the KEYS file and commit it > > +) you have to join a key signing party at some point in time > > > > Cheers, > > > > Siegfried Goeschl > > > > > > Ralph Goers wrote: > > > > > I have finished the work to implement webdav versioning support in VFS > > > trunk. I would like to take advantage of this in Commons Configuration > > > (that code is also complete) but to do so I need a release of VFS 2.0. > > > What must be done to accomplish this? FWIW I don't yet have a PGP key > > > so I kind of get stuck at that spot in the "creating releases" > > > instructions. > > > > > > Ralph > > > > > > > - > > > 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 commons-exec-1.0 based on RC5
[X] +1 release it :-) Siegfried Goeschl wrote: > Hi folks, > > here is the next release candidate for commons-exec-1.0 > > +) the findbugs configuration file is now part of the source > distribution so the site can be rebuild based on the source distribution > alone > +) using version number "1.0" instead of "1.0.0" > +) I failed to create an extended manifest for sources and javadoc jars > (not really important and a parent pom issue) > > Cheers, > > Siegfried Goeschl > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0 > > Site: > > http://people.apache.org/builds/commons/exec/1.0/RC5/site/index.html > > Binaries: > > http://people.apache.org/builds/commons/exec/1.0/RC5/staged/org/apache/commons/commons-exec/1.0/ > > [ ] +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 Commons CLI 1.2 (RC7)
+1, finally ;-) Henri Yandell wrote: > Fixing the unit test failure that Jörg found. > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC7 > > Site remains unchanged: > > http://people.apache.org/~bayard/cli-1.2-rc1 > > Binaries: > > http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/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 Commons CLI 1.2 (RC7)
+1 Oliver Henri Yandell schrieb: Fixing the unit test failure that Jörg found. --- Tag: https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC7 Site remains unchanged: http://people.apache.org/~bayard/cli-1.2-rc1 Binaries: http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] 2.0 release
I'd be happy to do all that. But my understanding is that I can't do the release until all those steps are completed. I'd really like VFS 2.0 released asap. Since I'm also not on the PMC I can't even vote for the release. As far as I can tell I'm the only one committing code but I know I'm not the only one using VFS. Ralph On Mar 16, 2009, at 10:05 AM, Siegfried Goeschl wrote: Hi Ralph, +) see http://www.apache.org/dev/release-signing.html +) you can upload your key to a public key server even if it is not trusted yet +) afterwards you add it to the KEYS file and commit it +) you have to join a key signing party at some point in time Cheers, Siegfried Goeschl Ralph Goers wrote: I have finished the work to implement webdav versioning support in VFS trunk. I would like to take advantage of this in Commons Configuration (that code is also complete) but to do so I need a release of VFS 2.0. What must be done to accomplish this? FWIW I don't yet have a PGP key so I kind of get stuck at that spot in the "creating releases" instructions. Ralph - 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 Commons CLI 1.2 (RC7)
Lots of checkstyle warnings, but these don't seem to be blockers. +1 Luc Siegfried Goeschl a écrit : > +1 > > Tested on Mac OS 10.4.1 using JDK 1.4.2 and 1.5.0 > > Cheers, > > Siegfried Goeschl > > Henri Yandell wrote: >> Fixing the unit test failure that Jörg found. >> >> --- >> >> Tag: >> >> https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC7 >> >> Site remains unchanged: >> >> http://people.apache.org/~bayard/cli-1.2-rc1 >> >> Binaries: >> >> http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/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 >> >> >> >> > > - > 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 commons-exec-1.0 based on RC5
+1 Oliver Siegfried Goeschl schrieb: Hi folks, here is the next release candidate for commons-exec-1.0 +) the findbugs configuration file is now part of the source distribution so the site can be rebuild based on the source distribution alone +) using version number "1.0" instead of "1.0.0" +) I failed to create an extended manifest for sources and javadoc jars (not really important and a parent pom issue) Cheers, Siegfried Goeschl --- Tag: https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0 Site: http://people.apache.org/builds/commons/exec/1.0/RC5/site/index.html Binaries: http://people.apache.org/builds/commons/exec/1.0/RC5/staged/org/apache/commons/commons-exec/1.0/ [ ] +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.2 RC3
Unless something has changed, the current test cases do include hsqldb based tests. The specific issue is that some of the changes in the proposed 1.2 have a specific impact on specific databases ( notably, oracle ) -- so it would be extremely useful if someone who has some access to some oracle instances could run some basic tests. Cheers -L On Mon, Mar 16, 2009 at 3:24 PM, James Carman wrote: > Why can't our test suite include some hsqldb-based tests? We do that at > work to test our hibernate queries and stuff. Each test case class gets > their own in-memory database. Performance isn't an issue > > On Mar 15, 2009 3:10 PM, "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 Commons CLI 1.2 (RC7)
+1 Tested on Mac OS 10.4.1 using JDK 1.4.2 and 1.5.0 Cheers, Siegfried Goeschl Henri Yandell wrote: > Fixing the unit test failure that Jörg found. > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC7 > > Site remains unchanged: > > http://people.apache.org/~bayard/cli-1.2-rc1 > > Binaries: > > http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/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 > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release Commons CLI 1.2 (RC7)
+1 Builds and tests pass (mvn clean site) on Windows XP SP3 for the following: Sun Java 1.6.0_12 Sun Java 1.5.0_13 Sun Java 1.4.2_19 Gary > -Original Message- > From: Henri Yandell [mailto:flame...@gmail.com] > Sent: Monday, March 16, 2009 12:36 AM > To: Commons Developers List > Subject: [VOTE] Release Commons CLI 1.2 (RC7) > > Fixing the unit test failure that Jörg found. > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC7 > > Site remains unchanged: > > http://people.apache.org/~bayard/cli-1.2-rc1 > > Binaries: > > http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons- > cli/commons-cli/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 - 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
Why can't our test suite include some hsqldb-based tests? We do that at work to test our hibernate queries and stuff. Each test case class gets their own in-memory database. Performance isn't an issue On Mar 15, 2009 3:10 PM, "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: [VFS] 2.0 release
Hi Ralph, +) see http://www.apache.org/dev/release-signing.html +) you can upload your key to a public key server even if it is not trusted yet +) afterwards you add it to the KEYS file and commit it +) you have to join a key signing party at some point in time Cheers, Siegfried Goeschl Ralph Goers wrote: > I have finished the work to implement webdav versioning support in VFS > trunk. I would like to take advantage of this in Commons Configuration > (that code is also complete) but to do so I need a release of VFS 2.0. > What must be done to accomplish this? FWIW I don't yet have a PGP key > so I kind of get stuck at that spot in the "creating releases" > instructions. > > Ralph > > - > 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
On 16/03/2009, Dan Fabulich wrote:
> 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.)
The vendor-specific DataSource code could be provided as examples too.
> 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);
>
> }
> }
Yes, that's the sort of thing I meant.
Works with Derby (after changing varchar=>varchar(32) likewise for char).
This could be extended to be a more extensive test of the features of
DBUtils against real databases.
> -
> 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: [LANG][GUMP] Take current Lang changes out of main Gump?
Henri Yandell wrote: > On Mon, Mar 16, 2009 at 5:59 AM, Stefan Bodewig > wrote: >> On 2009-03-16, sebb wrote: >> >>> I've not looked into this yet, but I think we can have two Lang builds >>> in Gump, one for the new stuff, and another for other projects. >> >> Easily, yes. >> >> Is there a branch that should be used by project that are likely to be >> broken by the changes in lang? > > The 2.4 tag. > > Having it fail was useful for me with the String Taglib; the code > needed to move off of deprecated methods. > > Personally I think failing is good and we'll learn lots from it. I'd > like to keep trunk until the consumer community indicate it's a pain > point. For example making a lang-backcompat jar for enum and > exceptions might be a better choice and getting projects to add a > dependency on that in gump. +1, this will directly show how "compatible" we are, since this be a major topic for all consumers of lang. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG][GUMP] Take current Lang changes out of main Gump?
On Mon, Mar 16, 2009 at 5:59 AM, Stefan Bodewig wrote: > On 2009-03-16, sebb wrote: > >> I've not looked into this yet, but I think we can have two Lang builds >> in Gump, one for the new stuff, and another for other projects. > > Easily, yes. > > Is there a branch that should be used by project that are likely to be > broken by the changes in lang? The 2.4 tag. Having it fail was useful for me with the String Taglib; the code needed to move off of deprecated methods. Personally I think failing is good and we'll learn lots from it. I'd like to keep trunk until the consumer community indicate it's a pain point. For example making a lang-backcompat jar for enum and exceptions might be a better choice and getting projects to add a dependency on that in gump. Hen - 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 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: [compress] Todos before release 1
Hi Stefan, good idea - cu on Wednesday ... Siegfried Goeschl Stefan Bodewig wrote: > On 2009-03-13, Siegfried Goeschl wrote: > > >> if Dennis has no time I can help out during Hackathon - I owe him one or >> two favours already for maven-related help >> > > I won't be there for the hackathon but arrive Wednesday. If you stay > around during the conference and could spare half an hour to bring me > up to speed WRT to mvn site maintenance and how it applies to commons > that would be great. > > Stefan > > - > 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 commons-exec-1.0 based on RC5
On 15/03/2009, Siegfried Goeschl wrote: > Hi folks, > > here is the next release candidate for commons-exec-1.0 > > +) the findbugs configuration file is now part of the source > distribution so the site can be rebuild based on the source distribution > alone > +) using version number "1.0" instead of "1.0.0" > +) I failed to create an extended manifest for sources and javadoc jars > (not really important and a parent pom issue) Not a blocker, but they are still not present. > Cheers, > > Siegfried Goeschl > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0 Nothing missing from source archive apart from the DOAP file (which is good). > Site: > > http://people.apache.org/builds/commons/exec/1.0/RC5/site/index.html No Download page. Java requirements are not mentioned. These are not blocking on the release, but need to be fixed before updating the published site. > Binaries: > > > http://people.apache.org/builds/commons/exec/1.0/RC5/staged/org/apache/commons/commons-exec/1.0/ Sigs hashes OK. N&L files OK. mvn test works OK in Java 1.4 ant test works OK in Java 1.3.1/Ant160, however the JUnit jar is not picked up from the local repo. Some changes are needed to build.xml if the JUnit jar is not already in the Ant classpath. Not a blocker; I'll commit these to trunk in case there is another release targetted at Java 1.3. Also the Ant build file fails to put N & L in the jar file. I suggest this target is removed from the build file - i.e. the file is only provided for confirming that the source builds and tests OK under 1.3, not for creating releases etc. Not a blocker. I think there may be some thread-safety issues, but as the documentation does not guarantee thread-safety these can be left for a possible further release. > > [ ] +1 release it +1 > [ ] +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: [compress] Todos before release 1
On 2009-03-13, Siegfried Goeschl wrote: > if Dennis has no time I can help out during Hackathon - I owe him one or > two favours already for maven-related help I won't be there for the hackathon but arrive Wednesday. If you stay around during the conference and could spare half an hour to bring me up to speed WRT to mvn site maintenance and how it applies to commons that would be great. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG][GUMP] Take current Lang changes out of main Gump?
On 2009-03-16, sebb wrote: > I've not looked into this yet, but I think we can have two Lang builds > in Gump, one for the new stuff, and another for other projects. Easily, yes. Is there a branch that should be used by project that are likely to be broken by the changes in lang? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] Todos before release 1
Hi, On Fri, Mar 13, 2009 at 11:33 PM, Siegfried Goeschl wrote: > if Dennis has no time I can help out during Hackathon I'd be happy to help with any compress-related stuff on Tuesday during the Hackathon. BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Promote Compress to Commons Proper
Hi, On Fri, Mar 13, 2009 at 4:58 AM, Stefan Bodewig wrote: > The compress component shall become a proper Commons component: [x] +1 Yes BR, Jukka Zitting - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[LANG][GUMP] Take current Lang changes out of main Gump?
The changes to Lang in trunk are likely to break lots of Gump builds. Since the changes are a work in progress, and we are not trying specifically to maintain backwards API compatibility, it seems unhelpful to cause other projects Gump grief just yet, as they will miss out on detecting other changes that break the build. I've not looked into this yet, but I think we can have two Lang builds in Gump, one for the new stuff, and another for other projects. WDYT? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-exec-1.0 based on RC5
+1 Luc - "Siegfried Goeschl" a écrit : > Hi folks, > > here is the next release candidate for commons-exec-1.0 > > +) the findbugs configuration file is now part of the source > distribution so the site can be rebuild based on the source > distribution > alone > +) using version number "1.0" instead of "1.0.0" > +) I failed to create an extended manifest for sources and javadoc > jars > (not really important and a parent pom issue) > > Cheers, > > Siegfried Goeschl > > --- > > Tag: > > https://svn.apache.org/repos/asf/commons/proper/exec/tags/EXEC_1_0 > > Site: > > http://people.apache.org/builds/commons/exec/1.0/RC5/site/index.html > > Binaries: > > http://people.apache.org/builds/commons/exec/1.0/RC5/staged/org/apache/commons/commons-exec/1.0/ > > [ ] +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
[g...@vmgump]: Project commons-configuration (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-configuration has an issue affecting its community integration. This issue affects 16 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration : Apache Commons - commons-configuration-test : Apache Commons - commons-jelly-tags-ojb : Commons Jelly - db-ojb-from-packages-1-0-release : ObjectRelationalBridge - db-torque : Persistence Layer - fulcrum-cache : Services Framework - fulcrum-configuration-impl : Services Framework - fulcrum-intake : Services Framework - fulcrum-parser : Services Framework - fulcrum-security-memory : Services Framework - fulcrum-security-nt : Services Framework - fulcrum-template : Services Framework - jakarta-turbine-jcs : Cache - portals-jetspeed-1 : Enterprise Information Portal - test-ojb-from-packages-1-0-release : ObjectRelationalBridge - turbine-core : A servlet based framework. Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole output [commons-configuration-1.7-SNAPSHOT.jar] identifier set to project name -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration/gump_work/build_apache-commons_commons-configuration.html Work Name: build_apache-commons_commons-configuration (Type: Build) Work ended in a state of : Failed Elapsed: 27 secs Command Line: mvn --batch-mode -Dmaven.test.skip=true --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/junit/dist/junit-16032009.jar - required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[197,45] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[202,39] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[207,37] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[212,46] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[217,63] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[447,43] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/AbstractHierarchicalFileConfiguration.java:[452,44] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/org/apache/commons/configuration/plist/PropertyListConfiguration.java:[157,61] incompatible types found : org.apache.commons.configuration.ConfigurationException required: java.lang.Throwable /srv/gump/public/workspace/apache-commons/configuration/src/java/or
[VOTE] Release Commons CLI 1.2 (RC7)
Fixing the unit test failure that Jörg found. --- Tag: https://svn.apache.org/repos/asf/commons/proper/cli/tags/cli-1.2-RC7 Site remains unchanged: http://people.apache.org/~bayard/cli-1.2-rc1 Binaries: http://people.apache.org/builds/commons/cli/1.2/RC7/staged/commons-cli/commons-cli/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 Commons CLI 1.2 (RC6)
On Sun, Mar 15, 2009 at 11:15 PM, Jörg Schaible wrote: > Jörg Schaible wrote: > >> Hi Hen, >> >> Henri Yandell wrote: >> >>> On Thu, Mar 12, 2009 at 4:12 PM, Jörg Schaible >>> wrote: >> >> [snip] >> Therefore we may either ensure that a call to create will always reset the builder in case of an IAE (CLI-177) or we can simply fix the tests that use the builder by calling reset manually in the setUp (actually we must create a simple option, since reset is private). Shall I commit this? >>> >>> I think fixing the tests and adding javadoc is best right now. We can >>> evaluate CLI-177 after that, but I don't want to hold up a release and >>> this is the kind of fix that would be nice to have sitting in trunk >>> for a while being picked up by people before baking it in. >>> >>> Let me know when you've done that and I'll spin another RC out. >> >> Have a look at CLI-177, it's simply a call to OptionBuilder.reset in a >> finally block instead in the end of normal application flow and an >> explicit call before an IAE (and a unit tests). Therefore I'd tend to fix >> it properly here, simply because it's not really changing standard >> behavior, but prevents from random settings injection. Fixing the tests by >> invoking reset in setUp is more a hack, since the reset method is not >> public. I simply did not want to commit CLI-177 without agreement in the >> middle of an RC. > > Hen? Sorry - got distracted. I get it now; not a change in the normal usage and so worth another RC. I've applied the patch and will rebuild a new version of the dist. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
