Re: [JEXL] Running 2.0.1 Tests (slightly modified) against 2.1-SNAPSHOT code
On 3 December 2011 00:08, sebb seb...@gmail.com wrote: To run the 2.0.1 tests against 2.1-SNAPSHOT, I have set up the branch https://svn.apache.org/repos/asf/commons/proper/jexl/branches/COMMONS_JEXL_2_0_1_TEST This is a copy ot the 2.0.1 tag, with minimal changes to the tests to handle new features in the script engine, and minor error message text changes. Download and compile the tests. It also contains a pom-text.xml which can be used to test against 2.1-SNAPSHOT (which I have uploaded). Just run: mvn -f pom-test.xml which invokes surefire:test. I've now updated the tests to check the ENGINE version of the JexlScriptEngineFactory (this changed from 1.0 to 2.0). This allows the tests to run locally and against 2.1; also clearly shows the differences in the test cases. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1209685 - /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ConfigurationFactory.java
Hi Stefan, thank you for your insights. Am 03.12.2011 08:25, schrieb Stefan Bodewig: Hi Oliver, On 2011-12-02,ohe...@apache.org wrote: Another attempt to fix the GUMP build using an ugly cast. Seeing you jumping through these hoops I wonder whether it wouldn't be better to look at the core issue. If configuration's compilation only fails in Gump this means there is an API broken between the component version you have specified (Digester 1.8.1) and the version provided by Gump (Digester from DIGESTER_2_X branch). The change in digester happened about three years ago http://svn.apache.org/viewvc/commons/proper/digester/branches/DIGESTER_2_X/src/main/java/org/apache/commons/digester/substitution/MultiVariableExpander.java?r1=560660r2=729129 Is configuration's dependency on Digester new or why have we started to see this error just now? You may want to upgrade to Digester 2.0 or 2.1 to start with (or even Digester3?) if it is new. If it isn't then obviously 2.x isn't compatible enough to 1.x for commons-configuration and we could think about a different solution. Configuration now targets Java 1.5 so we try to incorporate generics in the API without breaking binary compatibility in the first draft. In this special case this caused the problem that the plain Map we had before is now no more compatible with a MapString, Object expected by the digester class. What makes things a bit difficult to decide is the fact that the class affected in the Configuration code base (ConfigurationFactory) is actually deprecated, and it is the only one which requires the dependency to digester. Therefore there is not much motivation to do some major changes. Apart from that -MapObject, Object systemProperties = System.getProperties(); +// This is ugly, but it is safe because the Properties object returned +// by System.getProperties() (which is actually a MapObject, Object) +// contains only String keys. +@SuppressWarnings(unchecked) +MapString, Object systemProperties = +(MapString, Object) (Object) System.getProperties(); MultiVariableExpander expander = new MultiVariableExpander(); expander.addSource($, systemProperties); The assumption you make here may not always hold true. We've had several bug reports against Ant when we assumed the system properties would only hold string keys (or even values) and this simply was not true in cases where Ant code was used embedded in a larger application that was doing strange things. java.util.Properties will not prevent you from putting objects into it. I assume a commons component is at a bigger risk of such scenarios than an application like Ant. Even if it takes a bit longer it may be cleaner to create a new Map that contained a filtered view of only those properties that actually have string keys. I also thought about the copying approach, but then hoped that for system properties it would be safe to rely on String keys. Oliver 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
Properties not always String, String [was: svn commit: r1209685 - /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ConfigurationFactory.java]
On 3 December 2011 07:25, Stefan Bodewig bode...@apache.org wrote: Hi Oliver, On 2011-12-02, ohe...@apache.org wrote: Another attempt to fix the GUMP build using an ugly cast. - MapObject, Object systemProperties = System.getProperties(); + // This is ugly, but it is safe because the Properties object returned + // by System.getProperties() (which is actually a MapObject, Object) + // contains only String keys. + @SuppressWarnings(unchecked) + MapString, Object systemProperties = + (MapString, Object) (Object) System.getProperties(); MultiVariableExpander expander = new MultiVariableExpander(); expander.addSource($, systemProperties); The assumption you make here may not always hold true. We've had several bug reports against Ant when we assumed the system properties would only hold string keys (or even values) and this simply was not true in cases where Ant code was used embedded in a larger application that was doing strange things. java.util.Properties will not prevent you from putting objects into it. I assume a commons component is at a bigger risk of such scenarios than an application like Ant. That's very interesting; I suspect there are some other cases in Commons where we have made this assumption. [And probably in many other projects when converting to generics ...] However, if one uses java.util.Properties.load() or void java.util.Properties.loadXML() it should be OK, because the load method only creates Strings? Even if it takes a bit longer it may be cleaner to create a new Map that contained a filtered view of only those properties that actually have string keys. Good point. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
When building I get a heap space error in testSpeedCheck(org.apache.commons.codec.language.bm.BeiderMorseEncoderTest), even when setting MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the last RC. Which amount of memory is required? Otherwise, I did not find major problems. The site has two checkstyle links: one is clean, the other contains errors. Oliver Am 03.12.2011 04:06, schrieb Gary Gregory: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. [ ] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[JEXL] remaining binary incompatibilities in 2.1
The Jexl 2.0 branch now has only a few binary incompatibilities reported by Clirr. According to the JLS [1], adding methods to an interface does not break *binary* compatibility; however of course it will break source compatibility. Either Clirr is not distinguishing the binary/source cases, or it gets it wrong. The test case that I added to the 2.0.1 test branch confirms that new methods *can* be added. This just leaves the following errors, which do cause binary compatibilty problems: ERROR: 7006: org.apache.commons.jexl2.JexlEngine: Return type of method 'protected org.apache.commons.jexl2.JexlInfo createInfo(java.lang.String, int, int)' has been changed to org.apache.commons.jexl2.DebugInfo ERROR: 7006: org.apache.commons.jexl2.JexlEngine: Return type of method 'protected org.apache.commons.jexl2.JexlInfo debugInfo()' has been changed to org.apache.commons.jexl2.DebugInfo Now DebugInfo implements JexlInfo, and I think the method return types could/should be reverted to the original, i.e. JexlInfo. I've tested locally, and found that reverting to JexlInfo as the return type for the two methods does not cause any tests to fail. This is because currently the code accesses the DebugInfo class via JexlInfo#getDebugInfo(). WDYT? Would that be OK? If required, the additional DebugInfo methods could be added to the JexlInfo interface, after all the Javadoc says: Interface for objects carrying information usefull to debugging. The change needed to JexlEngine turns out to be very simple, basically just using JexlInfo instead of DebugInfo. [1] http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
On 3 December 2011 03:06, Gary Gregory ggreg...@apache.org wrote: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. And useless sig hashes generated by Maven or Nexus! These could be deleted before release - makes it easier to browse the directory. Otherwise looks fine; the cruft has gone - the source archive agrees with SVN. Also the test jar is included, which is good. [X] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [JEXL] remaining binary incompatibilities in 2.1
If the last hurdle to binary compatibility is replacing DebugInfo by JexlInfo, by all means, replace it! Nice analysis and great result. Thanks for your efforts, Cheers Henrib Ps any comment on the difference between stability and usability and possible solutions, cd release process post? -- View this message in context: http://apache-commons.680414.n4.nabble.com/JEXL-remaining-binary-incompatibilities-in-2-1-tp4153028p4153537.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1209685 - /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ConfigurationFactory.java
On 2011-12-03, Oliver Heger wrote: Is configuration's dependency on Digester new or why have we started to see this error just now? You may want to upgrade to Digester 2.0 or 2.1 to start with (or even Digester3?) if it is new. If it isn't then obviously 2.x isn't compatible enough to 1.x for commons-configuration and we could think about a different solution. Configuration now targets Java 1.5 so we try to incorporate generics in the API without breaking binary compatibility in the first draft. OK, I see. So as long as you target 1.4 Properties is good enough for the Digester 2.x interface. What makes things a bit difficult to decide is the fact that the class affected in the Configuration code base (ConfigurationFactory) is actually deprecated, and it is the only one which requires the dependency to digester. Therefore there is not much motivation to do some major changes. I can completely understand that and upgrading your Digester dependency would only make sure you see the same kinds of errors Gump sees during normal development. Not sure it would help your users much. We've had several bug reports against Ant when we assumed the system properties would only hold string keys (or even values) and this simply was not true in cases where Ant code was used embedded in a larger application that was doing strange things. java.util.Properties will not prevent you from putting objects into it. I assume a commons component is at a bigger risk of such scenarios than an application like Ant. Even if it takes a bit longer it may be cleaner to create a new Map that contained a filtered view of only those properties that actually have string keys. I also thought about the copying approach, but then hoped that for system properties it would be safe to rely on String keys. You can always wait for the first bug report 8-) Looking through MultiVariableExpander's code nothing in it really requires the map to only contain string keys, it will just ignore all others. Even if the system properties contained non-String keys it is very likely that nothing would break at all. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger oliver.he...@oliver-heger.dewrote: When building I get a heap space error in testSpeedCheck(org.apache.** commons.codec.language.bm.**BeiderMorseEncoderTest), even when setting MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the last RC. Which amount of memory is required? Try bumping up your MaxPermSize, for example: MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m Gary Otherwise, I did not find major problems. The site has two checkstyle links: one is clean, the other contains errors. Oliver Am 03.12.2011 04:06, schrieb Gary Gregory: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/**asf/commons/proper/codec/tags/** commons-codechttps://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/**builds/commons/codec/1.6/RC2/https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.**org/content/repositories/** orgapachecommons-224/https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/**content/repositories/** orgapachecommons-290/https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. [ ] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
On Sat, Dec 3, 2011 at 7:12 AM, sebb seb...@gmail.com wrote: On 3 December 2011 03:06, Gary Gregory ggreg...@apache.org wrote: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. And useless sig hashes generated by Maven or Nexus! These could be deleted before release - makes it easier to browse the directory. Thank you for the review. I don't like hand editing what Maven/Nexus spits out. There's room for a crabon-based error. G Otherwise looks fine; the cruft has gone - the source archive agrees with SVN. Also the test jar is included, which is good. [X] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 Spring Batch in Action: http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger oliver.he...@oliver-heger.dewrote: When building I get a heap space error in testSpeedCheck(org.apache.** commons.codec.language.bm.**BeiderMorseEncoderTest), even when setting MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the last RC. Which amount of memory is required? Otherwise, I did not find major problems. The site has two checkstyle links: one is clean, the other contains errors. I can't make sense of that either. Gary Oliver Am 03.12.2011 04:06, schrieb Gary Gregory: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/**asf/commons/proper/codec/tags/** commons-codechttps://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/**builds/commons/codec/1.6/RC2/https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.**org/content/repositories/** orgapachecommons-224/https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/**content/repositories/** orgapachecommons-290/https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. [ ] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [dbutils] Releasing 1.5
I took a look at the Continuum build error from Nov 26th and the error is that adding getSQLXML() in BeanProcessor.java requires importing java.sql.SQLXML which was introduced in Java 1.6. Currently DBUTILS is set to only require Java 1.5. Thoughts? Bill- On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Bill, Continuum just notified a build failure :P If you intend to cut a new release, read our `Creating Releases` page on wiki[1], count on me if you need help (I was the last on cutting a DbUtils release) Have a nice weekend, all the best! Simo [1] http://wiki.apache.org/commons/CreatingReleases http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs bill.spe...@gmail.com wrote: Does anyone have thoughts on releasing commons-dbutils 1.5? There are 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think that's probably enough to warrant a new release. I'm new to this whole process, so I'm unsure as to what to do next. Thanks... Bill- - 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] Releasing 1.5
On Sat, Dec 3, 2011 at 12:04 PM, William Speirs wspe...@apache.org wrote: I took a look at the Continuum build error from Nov 26th and the error is that adding getSQLXML() in BeanProcessor.java requires importing java.sql.SQLXML which was introduced in Java 1.6. Currently DBUTILS is set to only require Java 1.5. Thoughts? Require Java 6! :) Gary Bill- On Sat, Nov 26, 2011 at 4:09 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi Bill, Continuum just notified a build failure :P If you intend to cut a new release, read our `Creating Releases` page on wiki[1], count on me if you need help (I was the last on cutting a DbUtils release) Have a nice weekend, all the best! Simo [1] http://wiki.apache.org/commons/CreatingReleases http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Nov 26, 2011 at 9:22 PM, Bill Speirs bill.spe...@gmail.com wrote: Does anyone have thoughts on releasing commons-dbutils 1.5? There are 5 changes since 1.4 (issues 84, 77, 73, 67, and 66), and I think that's probably enough to warrant a new release. I'm new to this whole process, so I'm unsure as to what to do next. Thanks... Bill- - 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
Am 03.12.2011 17:18, schrieb Gary Gregory: On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger oliver.he...@oliver-heger.dewrote: When building I get a heap space error in testSpeedCheck(org.apache.** commons.codec.language.bm.**BeiderMorseEncoderTest), even when setting MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the last RC. Which amount of memory is required? Try bumping up your MaxPermSize, for example: MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m No luck either. As the error message indicates, the problem really seems to be related to heap size (AFAIK you get a specific perm gen error message otherwise). I get the same error message up to 1400 MB heap space. Unfortunately, I cannot increase my heap size beyond this value because I reach the limit of my physical memory. For a unit test these seem to be tough requirements. Oliver Gary Otherwise, I did not find major problems. The site has two checkstyle links: one is clean, the other contains errors. Oliver Am 03.12.2011 04:06, schrieb Gary Gregory: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/**asf/commons/proper/codec/tags/** commons-codechttps://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/**builds/commons/codec/1.6/RC2/https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.**org/content/repositories/** orgapachecommons-224/https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/**content/repositories/** orgapachecommons-290/https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. [ ] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-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] Stability versus usability
Since it may need clarification; The idea would be to allow a clirr report to give accurate analysis of whether the external / stable API has been modified. Methods or classes annotated as @stable, could not change from one version to another before they are @deprecated. Methods or classes annotated as @unstable (rather than @usable) could change between versions. The net result would be a good sense of whether the actual stable API is broken by a version and avoid lengthy discussions like the one we just had... Wouldn't this be possible to add to our toolbox as a clirr plugin of some kind? -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4154703.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX
On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger oliver.he...@oliver-heger.dewrote: Am 03.12.2011 17:18, schrieb Gary Gregory: On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger oliver.he...@oliver-heger.de**wrote: When building I get a heap space error in testSpeedCheck(org.apache.** commons.codec.language.bm.BeiderMorseEncoderTest), even when setting MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for the last RC. Which amount of memory is required? Try bumping up your MaxPermSize, for example: MAVEN_OPTS=-XX:MaxPermSize=**256m -Xmx1024m No luck either. As the error message indicates, the problem really seems to be related to heap size (AFAIK you get a specific perm gen error message otherwise). I get the same error message up to 1400 MB heap space. Unfortunately, I cannot increase my heap size beyond this value because I reach the limit of my physical memory. For a unit test these seem to be tough requirements. If I turn /off/ MAVEN_OPTS (set MAVEN_OPTS=) it still works for me, so that's good. I tied the 'mvn test' and 'mvn site'. After running site, Maven reports: [INFO] Final Memory: 43M/143M Gary Oliver Gary Otherwise, I did not find major problems. The site has two checkstyle links: one is clean, the other contains errors. Oliver Am 03.12.2011 04:06, schrieb Gary Gregory: Good day to you all: I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am not calling it RC3 because there are no changes in source files from the last RC. The only difference is that I built from a fresh checkout of the RC2 svn tag. The changes from RC1 are what Sebb found: - EOL in sources - Cruft from a dirty build, so I built this RC as I should have the first time around with: - mvn clean - mvn deploy -Prelease Tag: https://svn.apache.org/repos/asf/commons/proper/codec/**tags/**https://svn.apache.org/repos/**asf/commons/proper/codec/tags/** commons-codechttps://svn.**apache.org/repos/asf/commons/** proper/codec/tags/commons-**codechttps://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec -1.6-RC2 Site: https://people.apache.org/builds/commons/codec/1.6/RC2/https://people.apache.org/**builds/commons/codec/1.6/RC2/ **https://people.apache.org/**builds/commons/codec/1.6/RC2/https://people.apache.org/builds/commons/codec/1.6/RC2/ Binaries: https://repository.apache.org/content/repositories/** orgapachecommons-224/https://**repository.apache.org/content/** repositories/orgapachecommons-**224/https://repository.apache.org/content/repositories/orgapachecommons-224/ https://repository.apache.org/content/repositories/**https://repository.apache.org/**content/repositories/** orgapachecommons-290/https://**repository.apache.org/content/** repositories/orgapachecommons-**290/https://repository.apache.org/content/repositories/orgapachecommons-290/ The link above includes checksum files. [ ] +1 release it [ ] +0 go ahead, I cannot take the time [ ] -1 no, do not release it because: This VOTE is open for 72 hours, until November 23 2011, 14:00 EST. Fixed Bugs: o Use standard Maven directory layout. Issue: CODEC-129. Thanks to ggregory. o Documentation spelling fixes. Issue: CODEC-128. Thanks toville.sky...@iki.fi . o Fix various character encoding issues in comments and test cases. Issue: CODEC-127. o ColognePhonetic Javadoc should use HTML entities for special characters. Issue: CODEC-123. Changes: o Implement a Beider-Morse phonetic matching codec. Issue: CODEC-125. Thanks to Matthew Pocock. o Migrate to Java 5. Issue: CODEC-119. o Migrate to JUnit 4. Issue: CODEC-120. Heads up: the Beider-Morse encoder tests take a long time to run (5 minutes). The code has been optimized. Thank you, Gary --** --**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apac**he.orghttp://apache.org dev-unsubscribe@**commons.apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: http://goog_1249600977http://bit.ly/ECvg0 Spring Batch in Action: http://s.apache.org/HOqhttp://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=15343projectId=75 Build statistics: State: Failed Previous State: Ok Started at: Sat 3 Dec 2011 21:37:19 + Finished at: Sat 3 Dec 2011 21:37:52 + Total time: 33s Build Trigger: Schedule Build Number: 132 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_26 Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-31-server arch: amd64 Family: unix SCM Changes: Changed: simonetripodi @ Sat 3 Dec 2011 20:23:25 + Comment: restored ObjectCreateRule constructor via meta XML declaration Files changed: /commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/ObjectCreateBuilder.java ( 1209995 ) /commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/xmlrules/ObjectCreateRule.java ( 1209995 ) /commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/xmlrules/ObjectParamRule.java ( 1209995 ) /commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/xmlrules/XmlRulesModule.java ( 1209995 ) /commons/proper/digester/trunk/src/main/resources/org/apache/commons/digester3/xmlrules/digester-rules.dtd ( 1209995 ) /commons/proper/digester/trunk/src/site/resources/dtds/digester-rules-3.0.dtd ( 1209995 ) /commons/proper/digester/trunk/src/test/java/org/apache/commons/digester3/Digester153TestCase.java ( 1209995 ) /commons/proper/digester/trunk/src/test/resources/org/apache/commons/digester3/xmlrules/constructor-testrules.xml ( 1209995 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 196 Failures: 3 Errors: 0 Success Rate: 98 Total time: 2.615 Test Failures: TestXmlRuleInfo testXmlRuleInfoExplicitFile : java.lang.AssertionError java.lang.AssertionError: expected:xmlrules1 but was:null at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.commons.digester3.plugins.TestXmlRuleInfo.testXmlRuleInfoExplicitFile(TestXmlRuleInfo.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at
[continuum] BUILD FAILURE: Apache Commons - Apache Commons Digester - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=15346projectId=75 Build statistics: State: Failed Previous State: Failed Started at: Sat 3 Dec 2011 22:40:44 + Finished at: Sat 3 Dec 2011 22:41:19 + Total time: 35s Build Trigger: Schedule Build Number: 132 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_26 Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_26 Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-31-server arch: amd64 Family: unix SCM Changes: Changed: simonetripodi @ Sat 3 Dec 2011 21:48:41 + Comment: fixed JIRA URL pattern Files changed: /commons/proper/digester/trunk/pom.xml ( 1210015 ) Changed: simonetripodi @ Sat 3 Dec 2011 21:50:58 + Comment: credited DIGESTER-153 to Matt who fixed the issues Files changed: /commons/proper/digester/trunk/src/changes/changes.xml ( 1210018 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 196 Failures: 3 Errors: 0 Success Rate: 98 Total time: 2.2669997 Test Failures: TestXmlRuleInfo testXmlRuleInfoExplicitFile : java.lang.AssertionError java.lang.AssertionError: expected:xmlrules1 but was:null at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:147) at org.apache.commons.digester3.plugins.TestXmlRuleInfo.testXmlRuleInfoExplicitFile(TestXmlRuleInfo.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at
Re: [RELEASE PROCESS] Stability versus usability
On 12/2/11 3:45 PM, henrib wrote: It seems to me we have a hard time allowing both stability and usability. Stability of APIs does not contradict usability of the library, at least should not. Some of us are looking for very long term/stable/high-quality solutions because they need to aggregate lost of components, the stability users. Others are looking for best-of-breed/narrow scope/malleable libraries a with a guaranteed quality, the usability users. Thus the importance of clearly stating in our libraries what is 'stable' and what is 'usable'. The expressiveness in the language itself is not enough to properly describe the contract made regarding each party; i.e. sometimes things have to be public but should not be considered part of the API that follow the major,minor - deprecation. I believe we can come up with a set of agreeable rules to please both camps be through some naming convention in packages and annotations. As an kickstart proposal, may be something as simple as 2 annotations actually could be enough: @stable, @usable. @stable meaning the contract this API represents will not change without being first @deprecated @usable meaning this API is valid for this major version but may change in each minor with no warning We might also use a clear 'internal' sub-package name as a frontier delimiter on the same rule. Thoughts ? I applaud the initiative and creative suggestion above. I wonder, though, what users would make of it. My first thought as a user would be to avoid ever using the unstable stuff but I can imagine scenarios where I might. In practical terms, it might be hard to decide what to put where. Can you provide some examples based on recent RCs? An easy baby step that I could personally get behind - and actually need in [math] - is adopting the .internal package name convention for classes that need to be public because they are used in multiple packages, but which are not intended for use by external applications and effectively exempt from version compatibility requirements. That could by itself provide a workaround for a lot of these issues. Phil Best regards, Henri -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html Sent from the Commons - Dev mailing list archive at Nabble.com. - 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] Stability versus usability
I applaud the initiative and creative suggestion above. I wonder, though, what users would make of it. My first thought as a user would be to avoid ever using the unstable stuff but I can imagine scenarios where I might. Hi, I was wondering the same thing, from a user perspective too. I would avoid using the unstable classes too, and would like to have a way to know if any unstable classes are being used in one of my projects :) Having a quick glance on clirr maven plug-in site, I couldn't find much about its configuration. What if instead of adding these annotations, we suggested this as configuration to clirr? This way, instead of using annotations, we would use something similar to: configuration stable classorg.apache/class /stable /configuration And clirr wouldn't report on classes not listed in the configuration. Just food for thought :-) Cheers, Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com De: Phil Steitz phil.ste...@gmail.com Para: Commons Developers List dev@commons.apache.org Enviadas: Sábado, 3 de Dezembro de 2011 23:22 Assunto: Re: [RELEASE PROCESS] Stability versus usability On 12/2/11 3:45 PM, henrib wrote: It seems to me we have a hard time allowing both stability and usability. Stability of APIs does not contradict usability of the library, at least should not. Some of us are looking for very long term/stable/high-quality solutions because they need to aggregate lost of components, the stability users. Others are looking for best-of-breed/narrow scope/malleable libraries a with a guaranteed quality, the usability users. Thus the importance of clearly stating in our libraries what is 'stable' and what is 'usable'. The expressiveness in the language itself is not enough to properly describe the contract made regarding each party; i.e. sometimes things have to be public but should not be considered part of the API that follow the major,minor - deprecation. I believe we can come up with a set of agreeable rules to please both camps be through some naming convention in packages and annotations. As an kickstart proposal, may be something as simple as 2 annotations actually could be enough: @stable, @usable. @stable meaning the contract this API represents will not change without being first @deprecated @usable meaning this API is valid for this major version but may change in each minor with no warning We might also use a clear 'internal' sub-package name as a frontier delimiter on the same rule. Thoughts ? I applaud the initiative and creative suggestion above. I wonder, though, what users would make of it. My first thought as a user would be to avoid ever using the unstable stuff but I can imagine scenarios where I might. In practical terms, it might be hard to decide what to put where. Can you provide some examples based on recent RCs? An easy baby step that I could personally get behind - and actually need in [math] - is adopting the .internal package name convention for classes that need to be public because they are used in multiple packages, but which are not intended for use by external applications and effectively exempt from version compatibility requirements. That could by itself provide a workaround for a lot of these issues. Phil Best regards, Henri -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4150322.html Sent from the Commons - Dev mailing list archive at Nabble.com. - 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
[GUMP@vmgump]: Project commons-exec-test (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-exec-test has an issue affecting its community integration. This issue affects 1 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-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 23 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:/home/kk/grass/data/4404.he5://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.019 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.026 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.024 ms Process completed in 2004 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2004 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8012 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.789 sec FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Sun Dec 04 02:35:19 UTC 2011 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1204122011, vmgump.apache.org:vmgump:1204122011 Gump E-mail Identifier (unique within run) #18. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3-test (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-digester3-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 78 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-digester3-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/digester/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/digester/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3-test/gump_work/build_apache-commons_commons-digester3-test.html Work Name: build_apache-commons_commons-digester3-test (Type: Build) Work ended in a state of : Failed Elapsed: 21 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/digester] M2_HOME: /opt/maven2 - Running org.apache.commons.digester3.RulesBaseTestCase Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.digester3.plugins.TestConfigurablePluginAttributes Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 sec Running org.apache.commons.digester3.plugins.TestDelegate Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec Running org.apache.commons.digester3.plugins.TestInline Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 sec Running org.apache.commons.digester3.plugins.TestDefaultPlugin Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec Running org.apache.commons.digester3.plugins.TestLocalRules Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.023 sec Running org.apache.commons.digester3.plugins.TestXmlRuleInfo Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.069 sec FAILURE! Running org.apache.commons.digester3.plugins.TestRuleInfo Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.041 sec Running org.apache.commons.digester3.plugins.TestRecursion Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec Running org.apache.commons.digester3.plugins.TestDeclaration Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.commons.digester3.CallMethodRuleTestCase Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.249 sec Running org.apache.commons.digester3.URLTestCase Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.034 sec Running org.apache.commons.digester3.ObjectParamRuleTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.digester3.TestFactoryCreate Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.088 sec Results : Failed tests: testXmlRuleInfoExplicitFile(org.apache.commons.digester3.plugins.TestXmlRuleInfo): expected:xmlrules1 but was:null testXmlRuleInfoExplicitResource(org.apache.commons.digester3.plugins.TestXmlRuleInfo): expected:xmlrules2 but was:null testXmlRuleImplicitResource(org.apache.commons.digester3.plugins.TestXmlRuleInfo): expected:xmlrules-ruleinfo but was:null Tests run: 196, Failures: 3, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/digester/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 20 seconds [INFO] Finished at: Sun Dec 04 03:11:28 UTC 2011 [INFO] Final Memory: 37M/89M [INFO] - To
[GUMP@vmgump]: Project commons-proxy-test (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-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 257 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 12 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.177 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Sun Dec 04 05:29:26 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
Re: [dbutils] Releasing 1.5
On 2011-12-03, William Speirs wrote: I also added my fingerprint to LDAP and I've created a RDF file as well, but again I don't yet see my info here: http://people.apache.org/committers.html Again, I'm guessing/hoping that it just takes a while to perform the sync. There are a bunch of shell scripts running CRONed that validate various things and two of them are complaining to the site-dev mailing list about a key that cannot be found on any key server. It is the key C95C557D8EC998319F75BD68E7954A57B0EC1E65 which seems to be yours. Maybe the scripts won't publish anything unless your key can be found via gpg --recv-keys . Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
On 2011-12-02, henrib wrote: It seems to me we have a hard time allowing both stability and usability. Stability of APIs does not contradict usability of the library, at least should not. I'm glad you say that right at the beginning as the versus in the subject line seems to imply something else. 8-) Some of us are looking for very long term/stable/high-quality solutions because they need to aggregate lost of components, the stability users. Others are looking for best-of-breed/narrow scope/malleable libraries a with a guaranteed quality, the usability users. [Aside: is best-of-breed really impossible in a stable environment?] I don't think this is all there is to it. As one of the few people who still see value in Gump I tend to be in the stability camp - if there really are only these two choices. But it is more about the impact a new release has on the users than the number of components anybody aggregates. I don't think anybody likes the idea of having to modify code every time you update your dependencies. Thus the importance of clearly stating in our libraries what is 'stable' and what is 'usable'. While I like the idea to explicitly mark what you consider a stable/reliable API I don't think I like the tags. Or at least the tag usable. That it implies the stable parts are not usable makes me itch. As an kickstart proposal, may be something as simple as 2 annotations actually could be enough: @stable, @usable. @stable meaning the contract this API represents will not change without being first @deprecated @usable meaning this API is valid for this major version but may change in each minor with no warning We might also use a clear 'internal' sub-package name as a frontier delimiter on the same rule. Maybe we actually have three sorts of public APIs * APIs that we promise not to break unless we perform a major relase in which case we also change package names (and artifactIds). This is what you call @stable. * APIs that may break in minor releases. What you call @usable There is some danger to it in that you mark too many parts unstable and forget about them. I really think users prefer stable APIs to begin with unless the unstable ones offer important features and promise to become stable at one point in time. Compress has a package that has *experimental* warnings in Javadocs all over the place. It has carried this label for four minor relases now. Is it still experimental? I think anything not @stable needs to be revisited from time to time. * APIs that are only public for technical reasons but really are internal to the component. I think these are different from what you call @usable. And these should be allowed to change without warning as long as users are aware of the policy. So yes, I understand and agree that we sometimes want to add features and push them out to users before we understand them well enough to provide a stable API. And I really welcome any approach of explicitly marking those parts so that users - and people reviewing releases - know what to expect. But I also think the non-stable APIs have to be reconsidered from time to time and eventually become stable. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RELEASE PROCESS] Stability versus usability
Phil Steitz wrote In practical terms, it might be hard to decide what to put where. Can you provide some examples based on recent RCs? When trying to release JEXL 2.1, the API was disrupted and the clirr report was outputing lots of clutter. As the dev, it became very hard to understand whether the change was actually breaking the intended stable API or just some internal methods or class. Then a lot of effort - thanks to sebb - had to be spent just to check and amend the code to restore the contract. The findbugs, cobertura, chekstyle reports mostly allow to assess quality, a usable clirr report would give us a good view of stability. Phil Steitz wrote An easy baby step that I could personally get behind - and actually need in [math] - is adopting the .internal package name convention For new packages or during major code overhaul, it definitely does the job. But it might be unpractical and requires lots of code moving around; I'm currently trying to achieve this with JEXL3 and it is a major refactor. Plus it requires creating interfaces or abstract classes to clearly delineate the API; it tilts the balance of effort towards stability and hinders the ability to add features (in the same timeframe) thus slows down innovation. The annotation would be convenient to (re)decorate code since it is very lightweight, easy to use and control. Instead of @unstable / @usable, may be an @internal annotation would carry the proper information and would follow the same idea as the package name. @internal annotated class/method or *internal* package mean use this at your own maintenance cost; it still allows users to code using them, does not forcibly close extensibility thus preserve innovative contributions and provides a clearer view of the stable contract. Seems like a win-win. Best regards, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156330.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
