Re: Problems with FileUpload 1.2.2
There is a snapshot on https://repository.apache.org/content/repositories/snapshots/commons-fileupload/commons-fileupload/1.2.3-SNAPSHOT/ On Fri, Mar 18, 2011 at 9:51 PM, Deven Phillips de...@dns.com wrote: Hello, I'm trying to compile the latest HEAD revision of FileUpload because I see that the headers issue for FileItem has been fixed, but I cannot get it to compile. I honestly know nothing about Maven, so please forgive me if this is apparent to many on the list. I see from the SVN repository that Jochen Wiedmann comitted the fix on March 16th, but how can I download and compile that version of the library? Thanks, -- Deven Phillips Systems Programmer DNS.com/Comwired, Inc. PH: (502) 442-2963 Skype: infosec812 -- I Am What I Am And That's All What I Yam (Popeye) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ANNOUNCE] Commons Skin 3 and Commons Parent 20 released
On 2011-03-19 03:50, sebb wrote: Commons Skin and Parent have been updated, mainly to support the new PMC trademark guidelines, but some plugins were also updated. In particular maven-site-plugin was updated to 2.2.1. Version 2.2 in Parent 17 and 18 has a bug which causes problems with some sites. This must be a typo of some kind. There is no 2.2.1 version of Maven Site Plugin. 2.2 is the latest released version. Commons Skin 3 changes (from 2) = - commons parent 5 = 18 - added support for code prettify - site.css now uses relative url for referencing css files, so offline sites work better - added template to support trademark footer; also supports $relativePath resolution; adds TM overlay support; allows absolute URLs in banner elements Commons Parent 19 changes (from 18) == - Apache Parent Pom 7= 9 - maven-antrun-plugin 1.3 = 1.5 - antrun config: change deprecated tasks to target - updated site plugin to 2.2.1 (2.2 is broken) - surefire 2.7.1 = 2.7.2 - javadoc 2.5 = 2.7 - add AL header to site.xml - use local copy of commons-logo, rather than linking to commons.a.o - always use absolute link for http://commons.a.o/ - commons skin 2=3 - added prettify css/javascript to improve source code formatting - license now points to http://www.apache.org/licenses/ as per branding guidelines - synchronise common menu items with commons-site - moved ApacheCon logo under ASF menu, and made it clickable - added trademark references to page footers - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-vfs2 (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-vfs2 has an issue affecting its community integration.
This issue affects 7 projects,
and has been outstanding for 31 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-configuration : Apache Commons
- commons-configuration-test : Apache Commons
- commons-vfs2 : Apache Commons
- commons-vfs2-sandbox : Apache Commons
- commons-vfs2-test : Apache Commons
- jakarta-turbine-jcs : Cache
- jcs : Cache
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-vfs2-*[0-9T].jar] identifier set to project
name
-INFO- Optional dependency doxia-site-renderer failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/gump_work/build_apache-commons_commons-vfs2.html
Work Name: build_apache-commons_commons-vfs2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 32 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven2
-
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[move] Moving 2 files to
/srv/gump/public/workspace/apache-commons/vfs/core/target/test-classes/test-data/code
[INFO] Executed tasks
[WARNING] DEPRECATED [systemProperties]: Use systemPropertyVariables instead.
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/srv/gump/public/workspace/apache-commons/vfs/core/target/commons-vfs2-2.0-SNAPSHOT.jar
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar:
/srv/gump/public/workspace/apache-commons/vfs/core/target/commons-vfs2-2.0-SNAPSHOT-tests.jar
[INFO]
[INFO] Building Commons VFS Examples
[INFO]task-segment: [package]
[INFO]
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource to META-INF
[INFO] Copying 1 resource to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/vfs/examples/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/apache-commons/vfs/examples/src/main/java/org/apache/commons/vfs2/libcheck/FtpCheck.java:[75,46]
cannot find symbol
symbol : method getSystemName()
location: class org.apache.commons.net.ftp.FTPClient
[INFO] 1error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/vfs/examples/src/main/java/org/apache/commons/vfs2/libcheck/FtpCheck.java:[75,46]
cannot find symbol
symbol : method getSystemName()
location: class org.apache.commons.net.ftp.FTPClient
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 31 seconds
[INFO] Finished at: Sat Mar 19 11:04:29 UTC 2011
[INFO] Final Memory: 46M/110M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/rss.xml
- Atom:
[GUMP@vmgump]: Project commons-scxml-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-scxml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 148 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-scxml-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-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/scxml/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html Work Name: build_apache-commons_commons-scxml-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/scxml] M2_HOME: /opt/maven2 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.357 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.186 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.814 sec FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.308 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.29 sec FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.324 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Sat Mar 19 11:15:55 UTC 2011 [INFO] Final Memory: 25M/61M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06000619032011, vmgump.apache.org:vmgump:06000619032011 Gump E-mail Identifier (unique within
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
Hi Rahul, thanks once again for the wise suggestions, much more than appreciated! I underestimated the importance of the users over the active developers, so I totally agree with you, moving to dormant is premature. I was aware about breaking APIs compatibility, since we had to face the same problem also in [pool2], I thought it would have been a good idea implementing the sandbox in the o.a.c.digester3[1] package, looks like it is compliant to the suggestions you proposed. I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we call a vote before going on? Many thanks in advance, have a nice day, Simo [1] http://s.apache.org/VLZ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 12:45 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Mar 16, 2011 at 2:31 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all mates!!! I need your support on advising our users that a new version of Digester is available on sandbox, I already sent more than once an email on users ML but never got a reply, maybe my name is not so influent between users or maybe the Digester is not so popular as I still think... but I wouldn't have wasted the time I invested :P So, IMHO there are few points that deserve our attention, such: * if the Digester is out of our users' interest, it should be - sadly! - moved to the Dormant; snip/ We've users, though no active developers beyond you -- as long as you're interested I think a move to dormant is premature. * if the previous tense is wrong: * just maintain the current implementation in trunk, or * evaluate if the new Digester3 is a good candidate to replace the proper one snap/ Third option would be to do both. More below. I'm sure that together we can find the right way, for those interested knowing more details, Digester3 docs is on[1] with samples. snip/ Having looked at the samples and API, its clearly not compatible (this is not a statement about its value). I don't think we should use the same Java packages (oac.digester.*) since this isn't a drop-in replacement. However, if you are keen on releasing this (I don't have time to help in near future), an option would be to promote and release the sandbox code while keeping the oac.digester3.* packages. This would mean doing both: (a) retaining current code in 1.x and 2.x branches in case future releases need to be made on those lines and (b) moving sandbox code to trunk as 3.x line (while keeping the oac.digester3.* packages). -Rahul Looking forward to read from you soon, have a nice day!!! Simo [1] http://commons.apache.org/sandbox/digester3/ http://people.apache.org/~simonetripodi/ http://www.99soft.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
[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 148 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: 16 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.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 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.013 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 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.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.163 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 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.019 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: 13 seconds [INFO] Finished at: Sat Mar 19 12:31:42 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
On 3/19/11 4:54 AM, Simone Tripodi wrote: Hi Rahul, thanks once again for the wise suggestions, much more than appreciated! I underestimated the importance of the users over the active developers, so I totally agree with you, moving to dormant is premature. I was aware about breaking APIs compatibility, since we had to face the same problem also in [pool2], I thought it would have been a good idea implementing the sandbox in the o.a.c.digester3[1] package, looks like it is compliant to the suggestions you proposed. I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we call a vote before going on? +1 I don't think we need a VOTE on this, I would say wait a couple of more days to make sure we have (lazy) consensus and then just do it. Phil Many thanks in advance, have a nice day, Simo [1] http://s.apache.org/VLZ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 12:45 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Mar 16, 2011 at 2:31 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all mates!!! I need your support on advising our users that a new version of Digester is available on sandbox, I already sent more than once an email on users ML but never got a reply, maybe my name is not so influent between users or maybe the Digester is not so popular as I still think... but I wouldn't have wasted the time I invested :P So, IMHO there are few points that deserve our attention, such: * if the Digester is out of our users' interest, it should be - sadly! - moved to the Dormant; snip/ We've users, though no active developers beyond you -- as long as you're interested I think a move to dormant is premature. * if the previous tense is wrong: * just maintain the current implementation in trunk, or * evaluate if the new Digester3 is a good candidate to replace the proper one snap/ Third option would be to do both. More below. I'm sure that together we can find the right way, for those interested knowing more details, Digester3 docs is on[1] with samples. snip/ Having looked at the samples and API, its clearly not compatible (this is not a statement about its value). I don't think we should use the same Java packages (oac.digester.*) since this isn't a drop-in replacement. However, if you are keen on releasing this (I don't have time to help in near future), an option would be to promote and release the sandbox code while keeping the oac.digester3.* packages. This would mean doing both: (a) retaining current code in 1.x and 2.x branches in case future releases need to be made on those lines and (b) moving sandbox code to trunk as 3.x line (while keeping the oac.digester3.* packages). -Rahul Looking forward to read from you soon, have a nice day!!! Simo [1] http://commons.apache.org/sandbox/digester3/ http://people.apache.org/~simonetripodi/ http://www.99soft.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: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
Hi Phil!!! thanks for you feedbacks!!! Sure, there's no rush, let's do things taking the needed time :) Have a nice weekend, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 4:05 PM, Phil Steitz phil.ste...@gmail.com wrote: On 3/19/11 4:54 AM, Simone Tripodi wrote: Hi Rahul, thanks once again for the wise suggestions, much more than appreciated! I underestimated the importance of the users over the active developers, so I totally agree with you, moving to dormant is premature. I was aware about breaking APIs compatibility, since we had to face the same problem also in [pool2], I thought it would have been a good idea implementing the sandbox in the o.a.c.digester3[1] package, looks like it is compliant to the suggestions you proposed. I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we call a vote before going on? +1 I don't think we need a VOTE on this, I would say wait a couple of more days to make sure we have (lazy) consensus and then just do it. Phil Many thanks in advance, have a nice day, Simo [1] http://s.apache.org/VLZ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 12:45 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Mar 16, 2011 at 2:31 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all mates!!! I need your support on advising our users that a new version of Digester is available on sandbox, I already sent more than once an email on users ML but never got a reply, maybe my name is not so influent between users or maybe the Digester is not so popular as I still think... but I wouldn't have wasted the time I invested :P So, IMHO there are few points that deserve our attention, such: * if the Digester is out of our users' interest, it should be - sadly! - moved to the Dormant; snip/ We've users, though no active developers beyond you -- as long as you're interested I think a move to dormant is premature. * if the previous tense is wrong: * just maintain the current implementation in trunk, or * evaluate if the new Digester3 is a good candidate to replace the proper one snap/ Third option would be to do both. More below. I'm sure that together we can find the right way, for those interested knowing more details, Digester3 docs is on[1] with samples. snip/ Having looked at the samples and API, its clearly not compatible (this is not a statement about its value). I don't think we should use the same Java packages (oac.digester.*) since this isn't a drop-in replacement. However, if you are keen on releasing this (I don't have time to help in near future), an option would be to promote and release the sandbox code while keeping the oac.digester3.* packages. This would mean doing both: (a) retaining current code in 1.x and 2.x branches in case future releases need to be made on those lines and (b) moving sandbox code to trunk as 3.x line (while keeping the oac.digester3.* packages). -Rahul Looking forward to read from you soon, have a nice day!!! Simo [1] http://commons.apache.org/sandbox/digester3/ http://people.apache.org/~simonetripodi/ http://www.99soft.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
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
Before the release we should improve the unit test coverage. A migration guide with step by step help would be a nice addition. Gary On Mar 16, 2011, at 14:31, Simone Tripodi simonetrip...@apache.org wrote: Hi all mates!!! I need your support on advising our users that a new version of Digester is available on sandbox, I already sent more than once an email on users ML but never got a reply, maybe my name is not so influent between users or maybe the Digester is not so popular as I still think... but I wouldn't have wasted the time I invested :P So, IMHO there are few points that deserve our attention, such: * if the Digester is out of our users' interest, it should be - sadly! - moved to the Dormant; * if the previous tense is wrong: * just maintain the current implementation in trunk, or * evaluate if the new Digester3 is a good candidate to replace the proper one I'm sure that together we can find the right way, for those interested knowing more details, Digester3 docs is on[1] with samples. Looking forward to read from you soon, have a nice day!!! Simo [1] http://commons.apache.org/sandbox/digester3/ http://people.apache.org/~simonetripodi/ http://www.99soft.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: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz phil.ste...@gmail.com wrote: On 3/19/11 4:54 AM, Simone Tripodi wrote: Hi Rahul, thanks once again for the wise suggestions, much more than appreciated! I underestimated the importance of the users over the active developers, so I totally agree with you, moving to dormant is premature. I was aware about breaking APIs compatibility, since we had to face the same problem also in [pool2], I thought it would have been a good idea implementing the sandbox in the o.a.c.digester3[1] package, looks like it is compliant to the suggestions you proposed. I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we call a vote before going on? +1 I don't think we need a VOTE on this, I would say wait a couple of more days to make sure we have (lazy) consensus and then just do it. snip/ Not that I care for more process, but I'd like to see 3+ of us say this is the API they'd like to see for digester3. We also generally require votes for getting stuff out of sandbox so a vote may not be a bad idea (even if this isn't a new component, its a new API -- and somewhere in there, the lines are blurred). I'm +0. -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [fileupload] Problems with FileUpload 1.2.2
Aha!! I couldn't find that link, despite my best efforts yesterday. Thanks!! Deven On 03/19/2011 04:11 AM, Jochen Wiedmann wrote: There is a snapshot on https://repository.apache.org/content/repositories/snapshots/commons-fileupload/commons-fileupload/1.2.3-SNAPSHOT/ On Fri, Mar 18, 2011 at 9:51 PM, Deven Phillipsde...@dns.com wrote: Hello, I'm trying to compile the latest HEAD revision of FileUpload because I see that the headers issue for FileItem has been fixed, but I cannot get it to compile. I honestly know nothing about Maven, so please forgive me if this is apparent to many on the list. I see from the SVN repository that Jochen Wiedmann comitted the fix on March 16th, but how can I download and compile that version of the library? Thanks, -- Deven Phillips Systems Programmer DNS.com/Comwired, Inc. PH: (502) 442-2963 Skype: infosec812 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
Hi all, thanks for the trust guys!!! I won't express my vote, it would be too incorrect IMHO. I'll keep my finger crossed to see at least the 3 consensus :) Have a nice weekend! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 8:27 PM, Matt Benson gudnabr...@gmail.com wrote: On Mar 19, 2011, at 11:05 AM, Rahul Akolkar wrote: On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz phil.ste...@gmail.com wrote: On 3/19/11 4:54 AM, Simone Tripodi wrote: Hi Rahul, thanks once again for the wise suggestions, much more than appreciated! I underestimated the importance of the users over the active developers, so I totally agree with you, moving to dormant is premature. I was aware about breaking APIs compatibility, since we had to face the same problem also in [pool2], I thought it would have been a good idea implementing the sandbox in the o.a.c.digester3[1] package, looks like it is compliant to the suggestions you proposed. I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we call a vote before going on? +1 I don't think we need a VOTE on this, I would say wait a couple of more days to make sure we have (lazy) consensus and then just do it. snip/ Not that I care for more process, but I'd like to see 3+ of us say this is the API they'd like to see for digester3. We also generally require votes for getting stuff out of sandbox so a vote may not be a bad idea (even if this isn't a new component, its a new API -- and somewhere in there, the lines are blurred). I'm +0. I hesitate to throw in an opinion as I've never really used digester, but I quite like the API personally, and would +1 this. Matt -Rahul - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1083323 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/special/ test/java/org/apache/commons/math/special/
On 3/19/11 3:49 PM, er...@apache.org wrote:
Author: erans
Date: Sat Mar 19 22:49:59 2011
New Revision: 1083323
URL: http://svn.apache.org/viewvc?rev=1083323view=rev
Log:
MATH-446
Removed checked exceptions.
Some Javadoc cleanup.
Tests upgraded to Junit 4 (MATH-423).
Gilles,
This should have been done in three separate commits.
The first one, at least, should have been separated. It is easier
for reviewers and makes the commit log clearer if we separate
formatting / javadoc cleanup commits from those that update or
change the code. The JIRA reference will pull all of these diffs
under the referenced issue. It is better if the commits that
reference the issue are directly related to the issue.
Thanks,
Phil
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Beta.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Erf.java
commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Gamma.java
commons/proper/math/trunk/src/test/java/org/apache/commons/math/special/BetaTest.java
commons/proper/math/trunk/src/test/java/org/apache/commons/math/special/ErfTest.java
commons/proper/math/trunk/src/test/java/org/apache/commons/math/special/GammaTest.java
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Beta.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Beta.java?rev=1083323r1=1083322r2=1083323view=diff
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Beta.java
(original)
+++
commons/proper/math/trunk/src/main/java/org/apache/commons/math/special/Beta.java
Sat Mar 19 22:49:59 2011
@@ -16,7 +16,6 @@
*/
package org.apache.commons.math.special;
-import org.apache.commons.math.MathException;
import org.apache.commons.math.util.ContinuedFraction;
import org.apache.commons.math.util.FastMath;
@@ -27,31 +26,28 @@ import org.apache.commons.math.util.Fast
* @version $Revision$ $Date$
*/
public class Beta {
-
/** Maximum allowed numerical error. */
private static final double DEFAULT_EPSILON = 10e-15;
/**
* Default constructor. Prohibit instantiation.
*/
-private Beta() {
-super();
-}
+private Beta() {}
/**
* Returns the
* a href=http://mathworld.wolfram.com/RegularizedBetaFunction.html;
* regularized beta function/a I(x, a, b).
*
- * @param x the value.
- * @param a the a parameter.
- * @param b the b parameter.
- * @return the regularized beta function I(x, a, b)
+ * @param x Value.
+ * @param a Parameter {@code a}.
+ * @param b Parameter {@code b}.
+ * @return the regularized beta function I(x, a, b).
+ * @throws org.apache.commons.math.exception.MaxCountExceededException
+ * if the algorithm fails to converge.
* @throws MathException if the algorithm fails to converge.
*/
-public static double regularizedBeta(double x, double a, double b)
-throws MathException
-{
+public static double regularizedBeta(double x, double a, double b) {
return regularizedBeta(x, a, b, DEFAULT_EPSILON, Integer.MAX_VALUE);
}
@@ -60,18 +56,19 @@ public class Beta {
* a href=http://mathworld.wolfram.com/RegularizedBetaFunction.html;
* regularized beta function/a I(x, a, b).
*
- * @param x the value.
- * @param a the a parameter.
- * @param b the b parameter.
+ * @param x Value.
+ * @param a Parameter {@code a}.
+ * @param b Parameter {@code b}.
* @param epsilon When the absolute value of the nth item in the
- *series is less than epsilon the approximation ceases
- *to calculate further elements in the series.
+ * series is less than epsilon the approximation ceases to calculate
+ * further elements in the series.
* @return the regularized beta function I(x, a, b)
- * @throws MathException if the algorithm fails to converge.
+ * @throws org.apache.commons.math.exception.MaxCountExceededException
+ * if the algorithm fails to converge.
*/
-public static double regularizedBeta(double x, double a, double b,
-double epsilon) throws MathException
-{
+public static double regularizedBeta(double x,
+ double a, double b,
+ double epsilon) {
return regularizedBeta(x, a, b, epsilon, Integer.MAX_VALUE);
}
@@ -79,15 +76,16 @@ public class Beta {
* Returns the regularized beta function I(x, a, b).
*
* @param x the value.
- * @param a the a parameter.
- * @param b the b parameter.
+ * @param a
