Re: [pool] 1.5-RC1 available for review
Phil Steitz a écrit : > sebb wrote: >> On 29/05/2009, Phil Steitz wrote: >> >>> The files are here: >>> http://people.apache.org/~psteitz/commons-pool-1.5-RC1/ >>> >> >> findbugs filter and license-header.txt are missing from source archives. >> > This is intended. The associated reports are not enabled in the release > pom, so there is no reason to distribute these files with the release. >> RELEASE-NOTES.txt is missing from the SVN tag. I feel umcomfortable with this choice. Users may want to recompile from source themselves and modify the code to suit specific needs sometimes. It would be nice if in this case they could get the same level of confidence we have by enabling findbugs. If there are some known issues that we filter out (often false positive), they may encounter them too and wonder if their changes are to be blamed for this. Luc >> > This is a generated file. I guess I could check in before making the > tag, but then it would not be generated from the tag itself. >> NOTICE.txt has 2008. >> > Good catch. Thanks! >> I'm not sure why, but the $Id: SVN tags in some of the XML files >> differ between the source file and a checkout of the SVN tag. This >> should not happen if the tag is used to create the build. >> > The release was generated from the tag. Which files? >> It would be nice if the sources jar manifest had Spec. and Impl. entries. >> > Looks like you fixed this. Thanks! >> Ant test works OK on Java 1.3.1 >> >> Mvn test (Java 1.6.0) reports >> >> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered >> resources, i.e. build is platform dependent! >> >> Also the test fails for me: >> >> Failed tests: >> testBorrowObjectFairness(org.apache.commons.pool.impl.TestGenericObjectPool) >> >> Time elapsed: 2.468 sec <<< FAILURE! >> junit.framework.AssertionFailedError >> at junit.framework.Assert.fail(Assert.java:47) >> at junit.framework.Assert.fail(Assert.java:53) >> at >> org.apache.commons.pool.impl.TestGenericObjectPool.testBorrowObjectFairness(TestGenericObjectPool.java:1434) >> >> >> The Test case ought to be a bit more explicit as to why the test failed. >> >> I suspect it may be an error in the unit-test code - the TestThread >> class has various fields that are accessed across threads without any >> synchronisation. >> > I don't think the TestThread instance fields are accessed across > threads. The test case is timing sensitive, as indicated in the > comment. That said, this is a new test case, testing new code, so we > need to find out exactly what is going on. > > IIUC what the test is trying to do (Mark can correct me if I am wrong), > it is launching 500 threads, numbered by their array indices, with 10 > ms delays between starts and they confirming that they get served in > start order. The way that it confirms order is by leveraging the fact > that the test factory produces numbered objects, 0, 1, 2, , > maxActive - 1. So thread i should get object i mod maxActive. That is > what is being tested in the line you have narrowed the failure to. > > >> >>> The tag is here: >>> http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC1/ >>> >> >> NOTICE.txt says: >> >> Copyright 1999-2008 The Apache Software Foundation >> >> I think this does need to be fixed. >> >> DOAP file does not have an AL header (not a blocker, I'll fix trunk) >> > Thanks! > > Thanks for reviewing and for your help with the issues. > > Phil >> >>> Have at it! >>> >>> Thanks! >>> >>> Phil >>> >>> - >>> 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: [pool] 1.5-RC1 available for review
Luc Maisonobe wrote: Phil Steitz a écrit : sebb wrote: On 29/05/2009, Phil Steitz wrote: The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC1/ findbugs filter and license-header.txt are missing from source archives. This is intended. The associated reports are not enabled in the release pom, so there is no reason to distribute these files with the release. RELEASE-NOTES.txt is missing from the SVN tag. I feel umcomfortable with this choice. Users may want to recompile from source themselves and modify the code to suit specific needs sometimes. It would be nice if in this case they could get the same level of confidence we have by enabling findbugs. If there are some known issues that we filter out (often false positive), they may encounter them too and wonder if their changes are to be blamed for this. Interesting perspective. I will put the development reports back in. Thanks for the feedback. Phil Luc This is a generated file. I guess I could check in before making the tag, but then it would not be generated from the tag itself. NOTICE.txt has 2008. Good catch. Thanks! I'm not sure why, but the $Id: SVN tags in some of the XML files differ between the source file and a checkout of the SVN tag. This should not happen if the tag is used to create the build. The release was generated from the tag. Which files? It would be nice if the sources jar manifest had Spec. and Impl. entries. Looks like you fixed this. Thanks! Ant test works OK on Java 1.3.1 Mvn test (Java 1.6.0) reports [WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent! Also the test fails for me: Failed tests: testBorrowObjectFairness(org.apache.commons.pool.impl.TestGenericObjectPool) Time elapsed: 2.468 sec <<< FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.fail(Assert.java:53) at org.apache.commons.pool.impl.TestGenericObjectPool.testBorrowObjectFairness(TestGenericObjectPool.java:1434) The Test case ought to be a bit more explicit as to why the test failed. I suspect it may be an error in the unit-test code - the TestThread class has various fields that are accessed across threads without any synchronisation. I don't think the TestThread instance fields are accessed across threads. The test case is timing sensitive, as indicated in the comment. That said, this is a new test case, testing new code, so we need to find out exactly what is going on. IIUC what the test is trying to do (Mark can correct me if I am wrong), it is launching 500 threads, numbered by their array indices, with 10 ms delays between starts and they confirming that they get served in start order. The way that it confirms order is by leveraging the fact that the test factory produces numbered objects, 0, 1, 2, , maxActive - 1. So thread i should get object i mod maxActive. That is what is being tested in the line you have narrowed the failure to. The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC1/ NOTICE.txt says: Copyright 1999-2008 The Apache Software Foundation I think this does need to be fixed. DOAP file does not have an AL header (not a blocker, I'll fix trunk) Thanks! Thanks for reviewing and for your help with the issues. Phil Have at it! Thanks! Phil - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] Testing interface implementations
In Commons CLI there are 3 parsers implementing the same interface, and soon another implementation will be added. There is an abstract test case with the test methods, and a concrete subclass for each parser. The concrete test case instantiates the parser and disables some tests by overwriting them if they are known to fail. The abstract test is growing and becomes difficult to manage. I may split it into smaller classes grouping the tests by category, but I don't want to have 4 subclasses for every abstract class. This is where multi inheritance would be useful. Anyone knows a trick or a new test frameworks that may help testing the implementations of an interface? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC1 available for review
On 30/05/2009, Phil Steitz wrote: > sebb wrote: > > > On 30/05/2009, Phil Steitz wrote: > > > > > > > sebb wrote: > > > > > > > > > > > > > On 29/05/2009, Phil Steitz wrote: > > > > > > > > > > > > > > > > > > > > > The files are here: > > > > > > > > > > > > > > > > > > > > > > http://people.apache.org/~psteitz/commons-pool-1.5-RC1/ > > > > > > > > > > > > > > > > > > > > > > > > findbugs filter and license-header.txt are missing from source > archives. > > > > > > > > > > > > > > > > > > > This is intended. The associated reports are not enabled in the > release > > > pom, so there is no reason to distribute these files with the release. > > > > > > > > > > > > > OK. > > > > > > > > > > > > > RELEASE-NOTES.txt is missing from the SVN tag. > > > > > > > > > > > > > > > > > > > This is a generated file. I guess I could check in before making the > tag, > > > but then it would not be generated from the tag itself. > > > > > > > > > > OK, I did not realise it was auto generated. > > > > > > > > > > > > > NOTICE.txt has 2008. > > > > > > > > > > > > > > > > > > > Good catch. Thanks! > > > > > > > > > > > > > I'm not sure why, but the $Id: SVN tags in some of the XML files > > > > differ between the source file and a checkout of the SVN tag. This > > > > should not happen if the tag is used to create the build. > > > > > > > > > > > > > > > > > > > The release was generated from the tag. Which files? > > > > > > > > > > build.xml: > > SVN: > > SRC: > > > > downloads.xml > > examples.xml > > index.xml > > > > overview.html & package.html > > impl/package.html > > > > SVN info for the tag shows: > > > > Last Changed Author: psteitz > > Last Changed Rev: 779814 > > Last Changed Date: 2009-05-29 02:40:51 +0100 (Fri, 29 May 2009) > > > > > Thanks. I will investigate and fix in RC2. > > > > > > > > > > > > > It would be nice if the sources jar manifest had Spec. and Impl. > entries. > > > > > > > > > > > > > > > > > > > Looks like you fixed this. Thanks! > > > > > > > > > > > > > Ant test works OK on Java 1.3.1 > > > > > > > > Mvn test (Java 1.6.0) reports > > > > > > > > [WARNING] Using platform encoding (Cp1252 actually) to copy filtered > > > > resources, i.e. build is platform dependent! > > > > > > > > Also the test fails for me: > > > > > > > > Failed tests: > > > > > > > > > > > > > > > > testBorrowObjectFairness(org.apache.commons.pool.impl.TestGenericObjectPool) > > > > > > > > > > Time elapsed: 2.468 sec <<< FAILURE! > > > > junit.framework.AssertionFailedError > > > > at junit.framework.Assert.fail(Assert.java:47) > > > > at junit.framework.Assert.fail(Assert.java:53) > > > > at > > > > > > > > > > > > org.apache.commons.pool.impl.TestGenericObjectPool.testBorrowObjectFairness(TestGenericObjectPool.java:1434) > > > > > > > > > > The Test case ought to be a bit more explicit as to why the test > failed. > > > > > > > > I suspect it may be an error in the unit-test code - the TestThread > > > > class has various fields that are accessed across threads without any > > > > synchronisation. > > > > > > > > > > > > > > > > > > > I don't think the TestThread instance fields are accessed across > threads. > > > > > > > > > > The _failed and _complete booleans are set in one thread and read in > another. > > These need to be made volatile. > > > > Likewise the other class variables in TestThread, however these are > > set before the start() method and not accessed from the main thread > > again. > > > > > > > > > The test case is timing sensitive, as indicated in the comment. That > said, > > > this is a new test case, testing new code, so we need to find out > exactly > > > what is going on. > > > > > > > > > > I've added code to save the throwable (or generate one). > > > > > > > > > IIUC what the test is trying to do (Mark can correct me if I am wrong), > it > > > is launching 500 threads, numbered by their array indices, with 10 ms > > > delays between starts and they confirming that they get served in start > > > order. The way that it confirms order is by leveraging the fact that > the > > > test factory produces numbered objects, 0, 1, 2, , maxActive - 1. > So > > > thread i should get object i mod maxActive. That is what is being > tested in > > > the line you have narrowed the failure to. > > > > > > > > > > > > > It does seem to be a timing issue; if the delay in the startup loop is > > reduced, the error happens more readily, and if it is increased it > > happens less often. Perhaps it needs to be increased to 20ms from > > 10ms. > > > > > +1 for changing this to 20 ms. Does this eliminate the failures for you? Yes; and I've committed this to trunk. > To keep execution time under control, we should also reduce the number of > threads by, say 1/2 down to 250. Not necessary; there are only 30 threads in this test case. > Phil > > > > > > > > > > > > > > > > > > > > > > The tag is here: > > > > > > > > > > > > > > > > > > > > > > > http://svn.apache.or
Re: [all] Testing interface implementations
Emmanuel Bourg wrote: In Commons CLI there are 3 parsers implementing the same interface, and soon another implementation will be added. There is an abstract test case with the test methods, and a concrete subclass for each parser. The concrete test case instantiates the parser and disables some tests by overwriting them if they are known to fail. The abstract test is growing and becomes difficult to manage. I may split it into smaller classes grouping the tests by category, but I don't want to have 4 subclasses for every abstract class. This is where multi inheritance would be useful. Anyone knows a trick or a new test frameworks that may help testing the implementations of an interface? You have probably thought of this and it may be distasteful, but one way to break things apart would be to break the single abstract test class into an artificial hierarchy. If there is a way to do this with some kind of semantic integrity (e.g., if it can be made to coincide with the "known to fail" relation) that could be a simple solution. The [collections] test framework uses this approach, though the inheritance hierarchy among the test classes generally corresponds to specialization in the implementation classes. Phil Emmanuel Bourg - 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
[cli] New Parser available
The new parser has landed, get it while it's hot! It implements the features of the other parsers and more: - partial matching for the long options (-ver instead of -version) - options like Java memory settings are supported (-Xmx512m) - several corner cases have been fixed The parser passes all the tests of the other parsers, not only those in ParserTestCase. Have fun, Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
Very cool! You are taking all the fun stuff :) On Sat, May 30, 2009 at 04:13:38PM +0200, Emmanuel Bourg wrote: > The new parser has landed, get it while it's hot! > > It implements the features of the other parsers and more: > - partial matching for the long options (-ver instead of -version) > - options like Java memory settings are supported (-Xmx512m) > - several corner cases have been fixed > > The parser passes all the tests of the other parsers, not only those in > ParserTestCase. > > Have fun, > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org -- === Jim Jagielski [|] j...@jagunet.com [|] http://www.jaguNET.com/ "Great is the guilt of an unnecessary war" ~ John Adams - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
On Sat, 2009-05-30 at 16:13 +0200, Emmanuel Bourg wrote: > The new parser has landed, get it while it's hot! > > It implements the features of the other parsers and more: > - partial matching for the long options (-ver instead of -version) What about -ver being -v -e -r ? > - options like Java memory settings are supported (-Xmx512m) > - several corner cases have been fixed > > The parser passes all the tests of the other parsers, not only those in > ParserTestCase. > > Have fun, > > Emmanuel Bourg > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Russel. = Dr Russel Winder Partner xmpp: rus...@russel.org.uk Concertant LLPt: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.win...@ekiga.net London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [math] Serialization
Bill Barker wrote: - Original Message - From: "Ted Dunning" To: "Commons Developers List" Sent: Monday, May 25, 2009 4:52 PM Subject: Re: [math] Serialization This sounds like the germ of a repair process. Nuke all Serializable declarations without test cases. Then, add them back where people care enough to guarantee correctness by demonstrating a correct round trip. Would get my +1, but for the moment stats.** is such a mess (UID inherited from an abstract base class 3-4 levels up) that I'd like a consensus before putting hours into fixing it. +1 to fix. I was +1 in the early days when things were "overserialized" (IMO) [1] and am +1 today. [1] http://markmail.org/thread/ui47gz75ol5euxj4 Phil On Mon, May 25, 2009 at 4:32 PM, Bill Barker wrote: But again, want to ask advice before going terminator on those packages. IMHO, we'll need to write junit tests for the ones that we leave Serializable, since I already found (and fixed) two classes in linear that couldn't be de-serialized. -- Ted Dunning, CTO DeepDyve - 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: [cli] New Parser available
Russel Winder a écrit : It implements the features of the other parsers and more: - partial matching for the long options (-ver instead of -version) What about -ver being -v -e -r ? The partial matching of a long option has the priority over the decomposition of the short options. If you have the following options: -v,--verbose -e -r,--recursive then: 1. -ver will be parsed as -v (partial matching of 'verbose') 2. -rev will be parsed as -r -e -v (decomposition) I wonder if I should add some settings to control the behavior of the parser. For example, to disable the decomposition of the short options, or to disable the partial matching of the long options starting with a single dash (i.e --ver would still stand for --verbose, but not -ver). Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
Hey, On Sat, May 30, 2009 at 11:30 AM, Emmanuel Bourg wrote: > Russel Winder a écrit : > >>> It implements the features of the other parsers and more: >>> - partial matching for the long options (-ver instead of -version) >> >> What about -ver being -v -e -r ? > > The partial matching of a long option has the priority over the > decomposition of the short options. > > If you have the following options: > > -v,--verbose > -e > -r,--recursive > > then: > > 1. -ver will be parsed as -v (partial matching of 'verbose') > 2. -rev will be parsed as -r -e -v (decomposition) > > > I wonder if I should add some settings to control the behavior of the > parser. For example, to disable the decomposition of the short options, > or to disable the partial matching of the long options starting with a > single dash (i.e --ver would still stand for --verbose, but not -ver). I think partial matching should be disabled by default. While a neat feature to reduce typing, this behaviour will probably come as a surprise to people because it is not found in most programs. Also, if an option is not completely specified, I know I'd like the program to crash rather than run but do something that I don't expect. > Emmanuel Bourg Regards, James - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
On 30/05/2009, James Ring wrote: > Hey, > > > On Sat, May 30, 2009 at 11:30 AM, Emmanuel Bourg wrote: > > Russel Winder a écrit : > > > >>> It implements the features of the other parsers and more: > >>> - partial matching for the long options (-ver instead of -version) > >> > >> What about -ver being -v -e -r ? > > > > The partial matching of a long option has the priority over the > > decomposition of the short options. > > > > If you have the following options: > > > > -v,--verbose > > -e > > -r,--recursive > > > > then: > > > > 1. -ver will be parsed as -v (partial matching of 'verbose') > > 2. -rev will be parsed as -r -e -v (decomposition) > > > > > > I wonder if I should add some settings to control the behavior of the > > parser. For example, to disable the decomposition of the short options, > > or to disable the partial matching of the long options starting with a > > single dash (i.e --ver would still stand for --verbose, but not -ver). > > > I think partial matching should be disabled by default. While a neat > feature to reduce typing, this behaviour will probably come as a > surprise to people because it is not found in most programs. Also, if > an option is not completely specified, I know I'd like the program to > crash rather than run but do something that I don't expect. +1 > > Emmanuel Bourg > > Regards, > > James > > > - > 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-jelly-tags-fmt-test (in module commons-jelly) 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-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 8 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-30052009.jar:/srv/gump/pu blic/workspace/apache-commons/collections/build/commons-collections-30052009.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-30052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-30052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-30052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-30052009.jar:/srv/gump/public/workspace/apache-commons/jexl/dist/commons-jexl-30052009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-30052009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-30052009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-30052009.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags- fmt-30052009.jar - [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] ... 11 more [junit] Root cause [junit] java.lang.NoClassDefFoundError: org/apache/tools/ant/Main [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.getProject(AntTagLibrary.java:96) [junit] at org.apache.commons.jelly.tags.ant.AntTag.getAntProject(AntTag.java:310) [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:60) [junit] [junit] [junit] Testcase: testSetLocale(org.apache.commons.jelly.tags.junit.CaseTag$1): Caused an
Re: [all] Testing interface implementations
Phil Steitz a écrit : You have probably thought of this and it may be distasteful, but one way to break things apart would be to break the single abstract test class into an artificial hierarchy. If there is a way to do this with some kind of semantic integrity (e.g., if it can be made to coincide with the "known to fail" relation) that could be a simple solution. Yes that's probably the only solution. Thank you for the input. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
Jim Jagielski a écrit : Very cool! You are taking all the fun stuff :) Don't worry the party isn't over ;) I have a couple of things in mind like the option aliases, but I don't have the time to implement it yet. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
James Ring a écrit :
I think partial matching should be disabled by default. While a neat
feature to reduce typing, this behaviour will probably come as a
surprise to people because it is not found in most programs. Also, if
an option is not completely specified, I know I'd like the program to
crash rather than run but do something that I don't expect.
I believe a lot a GNU tools implement the partial matching for the long
options. For example "ls --col" is equivalent to "ls --color". Same
thing for mysql. But I haven't seen an application supporting the
partial matching with long options using a single dash ("java -ver"
doesn't work). I think I'll disable this case by default.
Emmanuel Bourg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[vfs] Google App Engine plug-in (GaeVFS)
The first public release (0.1) of GaeVFS is now available: http://gaevfs.appspot.com/ GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file system on top of the Google App Engine for Java (GAE) datastore. It provides a writeable file system for GAE, since GAE does not allow writing to the local file system. GaeVFS is licensed under the Apache License, Version 2.0. GaeVFS includes a servlet (GaeVfsServlet) that allows you to: - upload files into GaeVFS - serve files from GaeVFS - (optionally) perform GaeVFS directory listings The goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system (both reads and writes) that runs unmodified in either the GAE or "traditional" Java servlet environments. Please let me know if you find this useful.
[pool] 1.5-RC2 available for review
Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Testing interface implementations
Emmanuel Bourg wrote:
> In Commons CLI there are 3 parsers implementing the same interface, and soon
> another implementation will be added. There is an abstract test case with the
> test methods, and a concrete subclass for each parser. The concrete test case
> instantiates the parser and disables some tests by overwriting them if they
> are
> known to fail.
>
> The abstract test is growing and becomes difficult to manage. I may split it
> into smaller classes grouping the tests by category, but I don't want to have
> 4
> subclasses for every abstract class. This is where multi inheritance would be
> useful.
>
> Anyone knows a trick or a new test frameworks that may help testing the
> implementations of an interface?
The part about "The concrete test case [...] disables some tests [...] if they
are
known to fail" seems a bit dodgy to me from a design perspective. I offer as
evidence the very problem you describe.
I have not looked at the test code, but your plan to split up the abstract test
class is a good opportunity to solve this design problem. Here is what I
would try to do (assuming JUnit 3.x; otherwise YMMV):
1) Attempt to split the base class so that each resulting test class is either
100% go or 100% no-go for each parser. I would think that adopting Phil's
"semantic integrity" idea ought to do the job*, though I don't see a need for
the test classes to form a hierarchy**.
* If the known failures that are hidden by the current scheme are not directly
related to semantic considerations then why can't the tests be rewritten
so that all the implementations pass?
2) Instead of creating subclasses for (test class, implementation) pairs,
create a parser factory for each parser implementation, and give each test
class a list of the parser factories it should test. IOW, use composition
instead of inheritance. This isn't all that different from what you have
already, where the most important function of each concrete test class is
to function as a parser factory.
3) In implementing (2), build dynamic TestSuites in order to provide a
separate test for each (test method, parser implementation) pair. This
requires a static suite() method and puts much more burden on it than
in most test classes, but that is the price you pay for splitting up the
tests without either reducing test granularity or creating n * m
subclasses**.
Here's a schematic example:
public class CommonParserTests /* no need to extend TestCase */ {
private final ParserFactory factory;
public CommonParserTests(ParserFactory factory) {
this.factory = factory;
}
public void testDontHaveACow() {
CommandLineParser parser = factory.createParser();
CommandLine line = parser.parse(new Options(),
new String[] {"Don't", "have", "a", "cow,", "man!"});
// assertXXX...
}
// additional test methods as needed...
public static Test suite() {
TestSuite suite = new TestSuite();
for (ParserFactory factory : new ParserFactory[] {
new BasicParser(), new GnuParser(), new PosixParser()}) {
CommonParserTests tests = new CommonParserTests(factory);
suite.addTest(new TestCase("Don't have a cow, man!") {
protected void runTest() {
tests.testDontHaveACow();
}
});
// additional inner TestCases, one for each test method
}
return suite;
}
}
** Phil's suggestion of arranging the abstract test classes as a
hierarchy provides a simpler way of avoiding n * m concrete subclasses,
PROVIDED THAT there are no tests that crosscut part of the hierarchy.
That is, tests that want to appear in at least two, but not all, of the
abstract test classes don't fit well in an hierarchical scheme.
Regards,
John
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] Google App Engine plug-in (GaeVFS)
On May 30, 2009, at 2:55 PM, Vince Bonfanti wrote: The first public release (0.1) of GaeVFS is now available: http://gaevfs.appspot.com/ GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file system on top of the Google App Engine for Java (GAE) datastore. It provides a writeable file system for GAE, since GAE does not allow writing to the local file system. GaeVFS is licensed under the Apache License, Version 2.0. GaeVFS includes a servlet (GaeVfsServlet) that allows you to: - upload files into GaeVFS - serve files from GaeVFS - (optionally) perform GaeVFS directory listings The goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system (both reads and writes) that runs unmodified in either the GAE or "traditional" Java servlet environments. Please let me know if you find this useful. This is kind of cool. My first thought was that it might be nice to include it in VFS itself, but after looking at http://code.google.com/appengine/terms.html I have my doubts that including this at Apache would be doable even as an optional component. However, I see no reason it couldn't be referenced on the web site and added to providers.xml to load if it is present. Unless, of course, someone else has a different opinion. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] Google App Engine plug-in (GaeVFS)
good job man ! was working on a similar thing but used email accounts as storage. really nice job! On Sun, May 31, 2009 at 9:32 AM, Ralph Goers wrote: > > On May 30, 2009, at 2:55 PM, Vince Bonfanti wrote: > > The first public release (0.1) of GaeVFS is now available: >> >> http://gaevfs.appspot.com/ >> >> GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file >> system on top of the Google App Engine for Java (GAE) datastore. It >> provides >> a writeable file system for GAE, since GAE does not allow writing to the >> local file system. GaeVFS is licensed under the Apache License, Version >> 2.0. >> >> GaeVFS includes a servlet (GaeVfsServlet) that allows you to: >> >> - upload files into GaeVFS >> - serve files from GaeVFS >> - (optionally) perform GaeVFS directory listings >> >> The goal of GaeVFS is to provide a portability layer that allows you to >> write application code to access the file system (both reads and writes) >> that runs unmodified in either the GAE or "traditional" Java servlet >> environments. >> >> Please let me know if you find this useful. >> > > This is kind of cool. My first thought was that it might be nice to include > it in VFS itself, but after looking at > http://code.google.com/appengine/terms.html I have my doubts that > including this at Apache would be doable even as an optional component. > However, I see no reason it couldn't be referenced on the web site and added > to providers.xml to load if it is present. Unless, of course, someone else > has a different opinion. > > Ralph > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
