[g...@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 52 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- (Gump generated) 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: 19 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.005 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.37 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.046 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.019 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 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.034 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.221 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.052 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: 18 seconds [INFO] Finished at: Fri Nov 05 22:55:08 UTC 2010 [INFO] Final Memory: 39M/93M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/
[GUMP@vmgump]: Project commons-jelly-tags-quartz (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-quartz 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-quartz : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/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-jelly-tags-quartz-05112010.jar] identifier set to project name -DEBUG- Dependency on logging-log4j-12 exists, no need to add for property maven.jar.log4j. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports] -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/gump_work/build_commons-jelly_commons-jelly-tags-quartz.html Work Name: build_commons-jelly_commons-jelly-tags-quartz (Type: Build) Work ended in a state of : Failed Elapsed: 6 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz] - java:compile: [echo] Compiling to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] Compiling 7 source files to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:198: org.quartz.CronTrigger is abstract; cannot be instantiated [javac] CronTrigger trigger = new CronTrigger( getName(), [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:201: cannot find symbol [javac] symbol : method setCronExpression(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setCronExpression( getSpec() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:206: cannot find symbol [javac] symbol : method setJobName(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobName( getJobName() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:207: cannot find symbol [javac] symbol : method setJobGroup(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobGroup( getJobGroup() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:208: cannot find symbol [javac] symbol : method setStartTime(java.util.Date) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setStartTime( new Date() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:118: org.quartz.JobDetail is abstract; cannot be instantiated [javac] JobDetail detail = new JobDetail( getName(), [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:122: cannot find symbol [javac] symbol : method setDurability(boolean) [javac] location: interface org.quartz.JobDetail [javac] detail.setDurability( true ); [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quart
[g...@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 52 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- (Gump generated) 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: 40 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: 3.333 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.017 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.257 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 6.683 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.486 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.824 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.983 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: 38 seconds [INFO] Finished at: Fri Nov 05 21:50:03 UTC 2010 [INFO] Final Memory: 41M/99M [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 Gump version 2.3. Gump Run 28030605112010, vmgump.apache.org:vmgump:28030605112010 Gump E-mail Identifier (unique within run) #15. -- Apache
Re: [Math] FunctionEvaluationException in UnivariateRealFunction
Hello. > [...] Of course, I didn't overlook that you just ask for a @throws FunctionEvaluationException when the evaluation failed. Javadoc comment. I'm just reluctant to publicize a guideline that is not adhered to in CM! Whenever a method is passed an argument that doesn't fulfill pre-conditions, it throws an "IllegalArgumentException". But "FunctionEvaluationException" is not a subclass of "IllegalArgumentException". Users who are passed a "UnivariateRealFunction" instance should not rely that catching "FunctionEvaluationException" will work in most cases! So, should the Javadoc in fact be @throws IllegalArgumentException when the evaluation failed because of an invalid argument. @throws FunctionEvaluationException when the evaluation failed for any other reason. ? Then, how do you extend your guidelines to make it clear when to use one or the other? You could write a document that would explain how good it would be if all programs were using the same exceptions. But I must point out that CM isn't a good example, with its policy of no dependencies. Why would anyone depend on CM just for the sake of using CM exceptions? Best regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-vfs (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-vfs has an issue affecting its community integration.
This issue affects 48 projects,
and has been outstanding for 76 runs.
The current state of this project is 'Failed', with reason 'Missing Build
Outputs'.
For reference only, the following projects are affected by this:
- ant-contrib : Useful little Ant tasks
- ant-contrib-test : Useful little Ant tasks
- antbook-diary-core : Examples to go with Java Development with Ant
- antbook-sections : Examples to go with Java Development with Ant
- antbook-sections-tasks : Examples to go with Java Development with Ant
- cddlm : Configuration and Deployment of Grid Applications and System...
- commons-configuration : Apache Commons
- commons-configuration-test : Apache Commons
- commons-vfs : Apache Commons
- commons-vfs-sandbox : Apache Commons
- commons-vfs-test : Apache Commons
- excalibur-fortress-bean : Repository of reusable components.
- excalibur-fortress-container-impl : Repository of reusable components.
- excalibur-fortress-container-test : Repository of reusable components.
- excalibur-fortress-examples : Repository of reusable components.
- excalibur-fortress-migration : Repository of reusable components.
- excalibur-fortress-platform : Repository of reusable components.
- excalibur-fortress-testcase : Repository of reusable components.
- excalibur-monitor : Repository of reusable components.
- excalibur-sourceresolve : Repository of reusable components.
- excalibur-xmlutil : Repository of reusable components.
- excalibur-xmlutil-test : Repository of reusable components.
- forrest-core : Apache Forrest software is a publishing framework that
trans...
- forrest-rat : Apache Forrest software is a publishing framework that
trans...
- forrest-test : Apache Forrest software is a publishing framework that
trans...
- forrest-test-basic : Apache Forrest software is a publishing framework
that trans...
- fulcrum-cache : Services Framework
- fulcrum-cache-test : Services Framework
- fulcrum-configuration-impl : Services Framework
- fulcrum-security-memory : Services Framework
- fulcrum-security-nt : Services Framework
- fulcrum-template : Services Framework
- invicta : Open-source build management tool.
- ivy : Ivy Core
- ivy-tests : Ivy is a tool for managing (recording, tracking, resolving
a...
- jakarta-turbine-jcs : Cache
- jcs : Cache
- jgroups : A Reliable Multicast Communication Toolkit for Java
- logging-log4j-chainsaw : Chainsaw log viewer
- org.apache.commons_commons-vfs : Apache Commons
- smartfrog : Smartfrog: Application Deployment from HP Laboratories
- smartfrog-components : Smartfrog: Application Deployment from HP
Laboratories
- smartfrog-tasks : Smartfrog: Application Deployment from HP Laboratories
- smartfrog-tasks-test : Smartfrog: Application Deployment from HP
Laboratories
- smartfrog-test : Smartfrog: Application Deployment from HP Laboratories
- smartfrog-testharness : Smartfrog: Application Deployment from HP
Laboratories
- testng : Java Unit test framework
- testng-deps : Java Unit test framework
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs/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-vfs-2.0-SNAPSHOT.jar] identifier set to
project name
-DEBUG- (Gump generated) Maven Settings in:
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
-INFO- Failed with reason missing build outputs
-ERROR- Missing Output:
/srv/gump/public/workspace/apache-commons/vfs/core/target/commons-vfs-2.0-SNAPSHOT.jar
-ERROR- See Directory Listing Work for Missing Outputs
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs/gump_work/build_apache-commons_commons-vfs.html
Work Name: build_apache-commons_commons-vfs (Type: Build)
Work ended in a state of : Success
Elapsed: 2 mins 16 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] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 4:12 PM, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > Since the last candidate the jdk version has been changed to 1.5 and the > requirement has been added to the web site main page. The test file for > LargeTarTestCase has been added to the test-data directory, greatly improving > the build time. Many of the messages from the test cases have been removed. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... > -0 because I think the version number should be 1.1 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE] Release Commons VFS 2.0
This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and the requirement has been added to the web site main page. The test file for LargeTarTestCase has been added to the test-data directory, greatly improving the build time. Many of the messages from the test cases have been removed. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Ralph tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ (revision 1031749) site: http://people.apache.org/~rgoers/commons-vfs/index.html The following artifacts have been staged to the Apache Nexus Staging repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) https://repository.apache.org/content/repositories/orgapachecommons-038/ commons-vfs-examples-2.0.jar commons-vfs-examples-2.0.pom commons-vfs-examples-2.0-javadoc.jar commons-vfs-examples-2.0-sources.jar commons-vfs-examples-2.0.jar.asc commons-vfs-examples-2.0-sources.jar.asc commons-vfs-examples-2.0.pom.asc commons-vfs-examples-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar commons-vfs-2.0-test-sources.jar.asc commons-vfs-2.0-sources.jar.asc commons-vfs-2.0.jar commons-vfs-2.0.pom commons-vfs-2.0-test-sources.jar commons-vfs-2.0-javadoc.jar commons-vfs-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar.asc commons-vfs-2.0.pom.asc commons-vfs-2.0-sources.jar commons-vfs-2.0.jar.asc commons-vfs-sandbox-2.0-tests.jar.asc commons-vfs-sandbox-2.0-sources.jar commons-vfs-sandbox-2.0-tests.jar commons-vfs-sandbox-2.0-test-sources.jar.asc commons-vfs-sandbox-2.0-sources.jar.asc commons-vfs-sandbox-2.0.jar.asc commons-vfs-sandbox-2.0-test-sources.jar commons-vfs-sandbox-2.0-javadoc.jar commons-vfs-sandbox-2.0.pom commons-vfs-sandbox-2.0.jar commons-vfs-sandbox-2.0-javadoc.jar.asc commons-vfs-sandbox-2.0.pom.asc commons-vfs-distribution-2.0-src.zip commons-vfs-distribution-2.0.pom commons-vfs-distribution-2.0-src.tar.gz.asc commons-vfs-distribution-2.0-src.tar.gz commons-vfs-distribution-2.0-bin.zip commons-vfs-distribution-2.0-bin.zip.asc commons-vfs-distribution-2.0-bin.tar.gz commons-vfs-distribution-2.0-src.zip.asc commons-vfs-distribution-2.0-bin.tar.gz.asc commons-vfs-distribution-2.0.pom.asc commons-vfs-project-2.0-site.xml.asc commons-vfs-project-2.0.pom commons-vfs-project-2.0-site.xml commons-vfs-project-2.0.pom.asc
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 4:04 PM, sebb wrote: > I just don't think the need for consistency has been agreed. > Not by all, no. > I suggest you create a Wiki with the arguments so far (as I have > started for Maven groupId) > We need to come to a consensus about this JDK version requires a major version jump thing. We should also come to a consensus about artifactId/package/version staying in sync. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 20:00, James Carman wrote: > On Fri, Nov 5, 2010 at 3:56 PM, Ralph Goers > wrote: >> >> Simply bumping the JDK requirement is enough to go from 1.x to 2.x IMO. >> > > Again, I'm going to harp on the consistency factor. If we go to 2.0 > without changing artifactId and package, then future releases will be > inconsistent. See other threads about this discussion, as I do not > wish to re-hash it yet again. For this release, since it's binary > compatible, we can leave it at 1.1 to avoid introducing an > inconsistency. Others have argued that merely bumping JDK versions > isn't necessarily a reason to go to a new major version. I just don't think the need for consistency has been agreed. I suggest you create a Wiki with the arguments so far (as I have started for Maven groupId) +1 to using 2.0 for this release, without requiring package or groupId changes. > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 3:56 PM, Ralph Goers wrote: > > Simply bumping the JDK requirement is enough to go from 1.x to 2.x IMO. > Again, I'm going to harp on the consistency factor. If we go to 2.0 without changing artifactId and package, then future releases will be inconsistent. See other threads about this discussion, as I do not wish to re-hash it yet again. For this release, since it's binary compatible, we can leave it at 1.1 to avoid introducing an inconsistency. Others have argued that merely bumping JDK versions isn't necessarily a reason to go to a new major version. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 12:53 PM, James Carman wrote: > On Fri, Nov 5, 2010 at 1:37 PM, Jörg Schaible wrote: >> The first release in 4 years? ;-) >> >> We had the discussion for io 2.0 and therefore vfs 2.0 is fine for me also. >> We have new providers and a lot of closed JIRA issues. >> > > That's not enough to merit a major version jump, IMHO. Why not call it 1.1? > Simply bumping the JDK requirement is enough to go from 1.x to 2.x IMO. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1031735 - /commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
You weren't fast enough :-) I started rerunning the release already. Gotta
leave for the airport in 30 mins.
I've rerun the build several times already without problems.
The versions and upgrading JUnit can be done for the next release.
Ralph
On Nov 5, 2010, at 12:47 PM, sebb wrote:
> On 5 November 2010 19:32, Ralph Goers wrote:
>> I added the 3MB file to the test-data directory, so createLargeFile normally
>> won't run.
>
> Someone complained about adding that amount of test data, so I thought
> I'd fix it another way.
> Still safer though not to create a 3GB file ...
>
>> Are there any more changes? I'm ready to try the release again.
>
> I suggest you wait for the next Continuum build to complete at least.
>
> Also, should the code still depend on commons-httpclient 3.0?
> The current version in the 3.x line is 3.1
>
> Perhaps some other versions need to be adjusted.
>
> Certainly JUnit could be updated now we are using 1.5.
>
>>
>> Ralph
>>
>> On Nov 5, 2010, at 12:26 PM, s...@apache.org wrote:
>>
>>> Author: sebb
>>> Date: Fri Nov 5 19:26:06 2010
>>> New Revision: 1031735
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1031735&view=rev
>>> Log:
>>> Eliminate 3GB data file by using PipedI/O Streams
>>>
>>> Modified:
>>>
>>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>>>
>>> Modified:
>>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>>> URL:
>>> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java?rev=1031735&r1=1031734&r2=1031735&view=diff
>>> ==
>>> ---
>>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>>> (original)
>>> +++
>>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>>> Fri Nov 5 19:26:06 2010
>>> @@ -17,15 +17,16 @@
>>> package org.apache.commons.vfs.provider.tar.test;
>>>
>>> import java.io.File;
>>> -import java.io.FileInputStream;
>>> import java.io.FileOutputStream;
>>> -import java.io.InputStream;
>>> import java.io.OutputStream;
>>> +import java.io.PipedInputStream;
>>> +import java.io.PipedOutputStream;
>>> import java.util.Arrays;
>>> import java.util.Iterator;
>>> import java.util.List;
>>>
>>> import junit.framework.TestCase;
>>> +
>>> import org.apache.commons.compress.archivers.ArchiveStreamFactory;
>>> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
>>> import org.apache.commons.compress.archivers.tar.TarArchiveOutputStream;
>>> @@ -58,6 +59,7 @@ public class LargeTarTestCase extends Te
>>> manager.addProvider("tgz", new TarFileProvider());
>>> manager.addProvider("tar", new TarFileProvider());
>>>
>>> +new File(baseDir).mkdir(); // if test is run standalone
>>> createLargeFile(largeFilePath, largeFileName);
>>> }
>>>
>>> @@ -140,61 +142,66 @@ public class LargeTarTestCase extends Te
>>> }
>>>
>>> //@SuppressWarnings("unused")
>>> - protected void createLargeFile(String path, String name) throws
>>> Exception {
>>> -long _1K = 1024;
>>> -long _1M = 1024 * _1K;
>>> -long _256M = 256 * _1M;
>>> -long _512M = 512 * _1M;
>>> -long _1G = 1024 * _1M;
>>> + protected void createLargeFile(String path, final String name) throws
>>> Exception {
>>> +final long _1K = 1024;
>>> +final long _1M = 1024 * _1K;
>>> +//long _256M = 256 * _1M;
>>> +//long _512M = 512 * _1M;
>>> +final long _1G = 1024 * _1M;
>>>
>>> // File size of 3 GB
>>> -long fileSize = 3 * _1G;
>>> +final long fileSize = 3 * _1G;
>>>
>>> File tarGzFile = new File(path + name + ".tar.gz");
>>>
>>> if(!tarGzFile.exists()) {
>>> - System.out.println("This test is a bit slow. It needs to write a 3GB
>>> file to your hard drive");
>>> -
>>> - // Create archive
>>> - OutputStream outTarFileStream = new FileOutputStream(path + name +
>>> ".tar");
>>> -
>>> - TarArchiveOutputStream outTarStream = (TarArchiveOutputStream)new
>>> ArchiveStreamFactory()
>>> - .createArchiveOutputStream(ArchiveStreamFactory.TAR,
>>> outTarFileStream);
>>> -
>>> - // Create archive contents
>>> - TarArchiveEntry tarArchiveEntry = new TarArchiveEntry(name + ".txt");
>>> - tarArchiveEntry.setSize(fileSize);
>>> -
>>> - outTarStream.putArchiveEntry(tarArchiveEntry);
>>> - for(long i = 0; i < fileSize; i++) {
>>> -outTarStream.write('a');
>>> - }
>>> -
>>> - outTarStream.closeArchiveEntry();
>>> - outTarStream.close();
>>> -
>>> - outTarFileStream.close();
>>> + System.out.println("This test is a bit slow. It needs to write 3GB
>>> of data as a compressed file (approx. 3MB) to your hard drive");
>>>
>>> + final PipedOutputStr
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 1:37 PM, Jörg Schaible wrote: > The first release in 4 years? ;-) > > We had the discussion for io 2.0 and therefore vfs 2.0 is fine for me also. > We have new providers and a lot of closed JIRA issues. > That's not enough to merit a major version jump, IMHO. Why not call it 1.1? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1031735 - /commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
On 5 November 2010 19:32, Ralph Goers wrote:
> I added the 3MB file to the test-data directory, so createLargeFile normally
> won't run.
Someone complained about adding that amount of test data, so I thought
I'd fix it another way.
Still safer though not to create a 3GB file ...
> Are there any more changes? I'm ready to try the release again.
I suggest you wait for the next Continuum build to complete at least.
Also, should the code still depend on commons-httpclient 3.0?
The current version in the 3.x line is 3.1
Perhaps some other versions need to be adjusted.
Certainly JUnit could be updated now we are using 1.5.
>
> Ralph
>
> On Nov 5, 2010, at 12:26 PM, s...@apache.org wrote:
>
>> Author: sebb
>> Date: Fri Nov 5 19:26:06 2010
>> New Revision: 1031735
>>
>> URL: http://svn.apache.org/viewvc?rev=1031735&view=rev
>> Log:
>> Eliminate 3GB data file by using PipedI/O Streams
>>
>> Modified:
>>
>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>>
>> Modified:
>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>> URL:
>> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java?rev=1031735&r1=1031734&r2=1031735&view=diff
>> ==
>> ---
>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>> (original)
>> +++
>> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>> Fri Nov 5 19:26:06 2010
>> @@ -17,15 +17,16 @@
>> package org.apache.commons.vfs.provider.tar.test;
>>
>> import java.io.File;
>> -import java.io.FileInputStream;
>> import java.io.FileOutputStream;
>> -import java.io.InputStream;
>> import java.io.OutputStream;
>> +import java.io.PipedInputStream;
>> +import java.io.PipedOutputStream;
>> import java.util.Arrays;
>> import java.util.Iterator;
>> import java.util.List;
>>
>> import junit.framework.TestCase;
>> +
>> import org.apache.commons.compress.archivers.ArchiveStreamFactory;
>> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
>> import org.apache.commons.compress.archivers.tar.TarArchiveOutputStream;
>> @@ -58,6 +59,7 @@ public class LargeTarTestCase extends Te
>> manager.addProvider("tgz", new TarFileProvider());
>> manager.addProvider("tar", new TarFileProvider());
>>
>> + new File(baseDir).mkdir(); // if test is run standalone
>> createLargeFile(largeFilePath, largeFileName);
>> }
>>
>> @@ -140,61 +142,66 @@ public class LargeTarTestCase extends Te
>> }
>>
>> //@SuppressWarnings("unused")
>> - protected void createLargeFile(String path, String name) throws Exception
>> {
>> - long _1K = 1024;
>> - long _1M = 1024 * _1K;
>> - long _256M = 256 * _1M;
>> - long _512M = 512 * _1M;
>> - long _1G = 1024 * _1M;
>> + protected void createLargeFile(String path, final String name) throws
>> Exception {
>> + final long _1K = 1024;
>> + final long _1M = 1024 * _1K;
>> +// long _256M = 256 * _1M;
>> +// long _512M = 512 * _1M;
>> + final long _1G = 1024 * _1M;
>>
>> // File size of 3 GB
>> - long fileSize = 3 * _1G;
>> + final long fileSize = 3 * _1G;
>>
>> File tarGzFile = new File(path + name + ".tar.gz");
>>
>> if(!tarGzFile.exists()) {
>> - System.out.println("This test is a bit slow. It needs to write a 3GB
>> file to your hard drive");
>> -
>> - // Create archive
>> - OutputStream outTarFileStream = new FileOutputStream(path + name +
>> ".tar");
>> -
>> - TarArchiveOutputStream outTarStream = (TarArchiveOutputStream)new
>> ArchiveStreamFactory()
>> - .createArchiveOutputStream(ArchiveStreamFactory.TAR,
>> outTarFileStream);
>> -
>> - // Create archive contents
>> - TarArchiveEntry tarArchiveEntry = new TarArchiveEntry(name + ".txt");
>> - tarArchiveEntry.setSize(fileSize);
>> -
>> - outTarStream.putArchiveEntry(tarArchiveEntry);
>> - for(long i = 0; i < fileSize; i++) {
>> - outTarStream.write('a');
>> - }
>> -
>> - outTarStream.closeArchiveEntry();
>> - outTarStream.close();
>> -
>> - outTarFileStream.close();
>> + System.out.println("This test is a bit slow. It needs to write 3GB of
>> data as a compressed file (approx. 3MB) to your hard drive");
>>
>> + final PipedOutputStream outTarFileStream = new PipedOutputStream();
>> + PipedInputStream inTarFileStream = new
>> PipedInputStream(outTarFileStream);
>> +
>> + Thread source = new Thread(){
>> +
>> + public void run() {
>> + byte ba_1k[] = new byte[(int) _1K];
>> + for(int i=0; i < ba_1k.length; i++){
>> + ba_1k[i]='a';
>> + }
>> + try {
>> + TarArchiveOutputStream outTarStream
Re: svn commit: r1031735 - /commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
I added the 3MB file to the test-data directory, so createLargeFile normally
won't run.
Are there any more changes? I'm ready to try the release again.
Ralph
On Nov 5, 2010, at 12:26 PM, s...@apache.org wrote:
> Author: sebb
> Date: Fri Nov 5 19:26:06 2010
> New Revision: 1031735
>
> URL: http://svn.apache.org/viewvc?rev=1031735&view=rev
> Log:
> Eliminate 3GB data file by using PipedI/O Streams
>
> Modified:
>
> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
>
> Modified:
> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java?rev=1031735&r1=1031734&r2=1031735&view=diff
> ==
> ---
> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
> (original)
> +++
> commons/proper/vfs/trunk/core/src/test/java/org/apache/commons/vfs/provider/tar/test/LargeTarTestCase.java
> Fri Nov 5 19:26:06 2010
> @@ -17,15 +17,16 @@
> package org.apache.commons.vfs.provider.tar.test;
>
> import java.io.File;
> -import java.io.FileInputStream;
> import java.io.FileOutputStream;
> -import java.io.InputStream;
> import java.io.OutputStream;
> +import java.io.PipedInputStream;
> +import java.io.PipedOutputStream;
> import java.util.Arrays;
> import java.util.Iterator;
> import java.util.List;
>
> import junit.framework.TestCase;
> +
> import org.apache.commons.compress.archivers.ArchiveStreamFactory;
> import org.apache.commons.compress.archivers.tar.TarArchiveEntry;
> import org.apache.commons.compress.archivers.tar.TarArchiveOutputStream;
> @@ -58,6 +59,7 @@ public class LargeTarTestCase extends Te
> manager.addProvider("tgz", new TarFileProvider());
> manager.addProvider("tar", new TarFileProvider());
>
> +new File(baseDir).mkdir(); // if test is run standalone
> createLargeFile(largeFilePath, largeFileName);
> }
>
> @@ -140,61 +142,66 @@ public class LargeTarTestCase extends Te
> }
>
> //@SuppressWarnings("unused")
> - protected void createLargeFile(String path, String name) throws Exception {
> -long _1K = 1024;
> -long _1M = 1024 * _1K;
> -long _256M = 256 * _1M;
> -long _512M = 512 * _1M;
> -long _1G = 1024 * _1M;
> + protected void createLargeFile(String path, final String name) throws
> Exception {
> +final long _1K = 1024;
> +final long _1M = 1024 * _1K;
> +//long _256M = 256 * _1M;
> +//long _512M = 512 * _1M;
> +final long _1G = 1024 * _1M;
>
> // File size of 3 GB
> -long fileSize = 3 * _1G;
> +final long fileSize = 3 * _1G;
>
> File tarGzFile = new File(path + name + ".tar.gz");
>
> if(!tarGzFile.exists()) {
> - System.out.println("This test is a bit slow. It needs to write a 3GB
> file to your hard drive");
> -
> - // Create archive
> - OutputStream outTarFileStream = new FileOutputStream(path + name +
> ".tar");
> -
> - TarArchiveOutputStream outTarStream = (TarArchiveOutputStream)new
> ArchiveStreamFactory()
> - .createArchiveOutputStream(ArchiveStreamFactory.TAR, outTarFileStream);
> -
> - // Create archive contents
> - TarArchiveEntry tarArchiveEntry = new TarArchiveEntry(name + ".txt");
> - tarArchiveEntry.setSize(fileSize);
> -
> - outTarStream.putArchiveEntry(tarArchiveEntry);
> - for(long i = 0; i < fileSize; i++) {
> -outTarStream.write('a');
> - }
> -
> - outTarStream.closeArchiveEntry();
> - outTarStream.close();
> -
> - outTarFileStream.close();
> + System.out.println("This test is a bit slow. It needs to write 3GB of
> data as a compressed file (approx. 3MB) to your hard drive");
>
> + final PipedOutputStream outTarFileStream = new PipedOutputStream();
> + PipedInputStream inTarFileStream = new
> PipedInputStream(outTarFileStream);
> +
> + Thread source = new Thread(){
> +
> +public void run() {
> +byte ba_1k[] = new byte[(int) _1K];
> +for(int i=0; i < ba_1k.length; i++){
> +ba_1k[i]='a';
> +}
> +try {
> +TarArchiveOutputStream outTarStream =
> +(TarArchiveOutputStream)new ArchiveStreamFactory()
> +.createArchiveOutputStream(ArchiveStreamFactory.TAR,
> outTarFileStream);
> +// Create archive contents
> +TarArchiveEntry tarArchiveEntry = new TarArchiveEntry(name +
> ".txt");
> +tarArchiveEntry.setSize(fileSize);
> +
> +outTarStream.putArchiveEntry(tarArchiveEntry);
> +for(long i = 0; i < fileSize; i+= ba_1k.length) {
> +outTarStream.write(ba_1k);
> +}
> +
Re: [VFS] 2.0 update to Java 1.5 - generics etc?
On Nov 5, 2010, at 12:15 PM, sebb wrote: > If we do require a minimum of Java 1.5 for VFS 2.0, we probably also > need to ensure that the code compiles without warnings on Java 1.5. > > This would mean adding @Override etc. annotations and generics. > > Thoughts? > While that would be a good thing to do I certainly wouldn't want to require that. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] 2.0 update to Java 1.5 - generics etc?
On Nov 5, 2010, at 12:16, "sebb" wrote: > If we do require a minimum of Java 1.5 for VFS 2.0, we probably also > need to ensure that the code compiles without warnings on Java 1.5. > > This would mean adding @Override etc. annotations and generics. > > Thoughts? +1 but not a blocker Gary > > - > 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
[VFS] 2.0 update to Java 1.5 - generics etc?
If we do require a minimum of Java 1.5 for VFS 2.0, we probably also need to ensure that the code compiles without warnings on Java 1.5. This would mean adding @Override etc. annotations and generics. Thoughts? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
I think I'll add another standard descriptor to the default bundle, and then projects can opt for the tar.gz simply by setting a property. I'm hesitant to start causing all projects to generate two copies of the source archives by default, since many of them seem happy with just a zip. On Thu, Nov 4, 2010 at 2:28 PM, Henning Schmiedehausen wrote: > That makes lots of sense to standardize. > > So, if we standardize, IMHO we should standardize on provide both. It > really is only a single line in the default assembly. No big deal. > > -h > > > > On Thu, Nov 4, 2010 at 12:59, Brian Fox wrote: We need both zips and tars of the sources for the actual release (what we push to dist/). >> >>> Brian wants to know why. It certainly isn't mandated by the board. >> >> That gets me into trouble a lot of times. "Because we always have done >> it that way" is my favorite opportunity to ask why. You guys are >> certainly free to make tar.gz's if you want and I have nothing to say >> about it. However here's why I ask: >> >> We've tried to setup a standard profile in the apache pom that will >> meet the basic requirements for any Apache project using Maven to meet >> the things like LICENSE/NOTICE and signed source archives. So far, the >> zip has been sufficient for all the projects using it. I can't see any >> value in duplicating the source archive as a tar.gz because as I >> mentioned, it shouldn't normally have binaries and therefore the >> permissions are irrelevant. Since it's unlikely we would want to >> enable this for all projects, it means you would have to extend the >> profile in a way that causes you to diverge from the norm and it will >> make it harder to consume standard changes down the road. (in fact >> most of the troubles we've seen getting vfs released were related to >> undoing the legacy profile and using the standard one). >> >> So I wonder why a tar.gz sourceball is needed and is it worth it to >> diverge just for that. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... I've build the artifacts from the distributed src tarball and it went fine (incl. tests) with my compiler zoo for all compilers (Java >= 5, 64-bit, Linux). However, I did not run the different test profiles yet and it seems that strange things happen looking at James' FTP results using net 2.0, 1.4.1 and 1.4.0. At least for net-2.0 it should have worked. :-/ - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
sebb wrote: > On 5 November 2010 17:36, Jörg Schaible wrote: >> sebb wrote: >> >>> On 5 November 2010 17:11, Jörg Schaible wrote: Gary Gregory wrote: > One thing that drives me nuts is that most project do not list the JRE > requirements on the front page of the project. It's not even in the > project dependencies either. > > So we should at least update the docs IMO for Java 5. +1 Not a blocker though. However, it seems that the news section should have been really updated as proposed: Minimum Java 1.4 (or 5 - depends on what we decide). >>> >>> It's not possible currently to compile the core code using Java 1.4. >>> >>> Since we ship source, I think this is a blocker. >> >> Not if we increase the (documented) minimum Java version to 5 ;-) >> Then Ralph can release if the vote passes. > > But that requires a new RC to fix the version of Java which is in > pom.xml and of course in the Manifests. It does not really harm that the target JDK has been 1.4. > Possibly elsewhere too in the source files. > > Either way, I think we need a new RC. As long as minimum JDK is documented on the VFS home page, I'm fine with it for Java 5. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 17:36, Jörg Schaible wrote: > sebb wrote: > >> On 5 November 2010 17:11, Jörg Schaible wrote: >>> Gary Gregory wrote: >>> One thing that drives me nuts is that most project do not list the JRE requirements on the front page of the project. It's not even in the project dependencies either. So we should at least update the docs IMO for Java 5. >>> >>> +1 >>> >>> Not a blocker though. >>> >>> However, it seems that the news section should have been really updated >>> as proposed: Minimum Java 1.4 (or 5 - depends on what we decide). >> >> It's not possible currently to compile the core code using Java 1.4. >> >> Since we ship source, I think this is a blocker. > > Not if we increase the (documented) minimum Java version to 5 ;-) > Then Ralph can release if the vote passes. But that requires a new RC to fix the version of Java which is in pom.xml and of course in the Manifests. Possibly elsewhere too in the source files. Either way, I think we need a new RC. > - Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
James Carman wrote: > On Fri, Nov 5, 2010 at 1:01 PM, sebb wrote: >> >> Why change package names? Surely the API is compatible? If not, then a >> name change may be advisable even if staying with Java 1.4. >> > > Seems reasonable to me, but the question to be asked is, why do we > jump to 2.0 here? Is there really a revolutionary change going on? The first release in 4 years? ;-) We had the discussion for io 2.0 and therefore vfs 2.0 is fine for me also. We have new providers and a lot of closed JIRA issues. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
sebb wrote: > On 5 November 2010 17:11, Jörg Schaible wrote: >> Gary Gregory wrote: >> >>> One thing that drives me nuts is that most project do not list the JRE >>> requirements on the front page of the project. It's not even in the >>> project dependencies either. >>> >>> So we should at least update the docs IMO for Java 5. >> >> +1 >> >> Not a blocker though. >> >> However, it seems that the news section should have been really updated >> as proposed: Minimum Java 1.4 (or 5 - depends on what we decide). > > It's not possible currently to compile the core code using Java 1.4. > > Since we ship source, I think this is a blocker. Not if we increase the (documented) minimum Java version to 5 ;-) Then Ralph can release if the vote passes. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 10:20 AM, James Carman wrote: > On Fri, Nov 5, 2010 at 1:18 PM, sebb wrote: >> >> It's not possible currently to compile the core code using Java 1.4. >> >> Since we ship source, I think this is a blocker. >> > > And, it's easy to fix, so why not just cut a new RC? > Only because I was trying to do this before leaving Atlanta. Now that all the bugs have been worked out doing a re-release is fairly painless. I just don't know that I'll have any more time until I get home. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 17:15, Jörg Schaible wrote: > James Carman wrote: > >> On Fri, Nov 5, 2010 at 12:24 PM, James Carman >> wrote: >>> >>> Interestingly enough, the program fails when I put net 1.4.1 on the >>> classpath with: >>> >>> Exception in thread "main" >>> org.apache.commons.vfs.FileNotFoundException: Could not read from >>> "ftp://ftp.microsoft.com/MISC/CBCP.TXT"; because it is a not a file. >>> at >>> > org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1281) >>> at >>> > org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:394) >>> at com.carmanconsulting.vfs.App.main(App.java:38) Caused by: >>> java.io.FileNotFoundException: ftp://ftp.microsoft.com/MISC/CBCP.TXT at >>> > org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetInputStream(FtpFileObject.java:594) >>> at >>> > org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1273) >>> ... 2 more >>> >> >> Of course, it also fails with net 2.0. Weird. > > >:D > > Do you also try 2.2-SNAPSHOT ? > > When I look at http://commons.apache.org/net/changes-report.html and > http://commons.apache.org/net/clirr-report.html it seems that 2.2 is again > not really binary compatible anymore. That's a separate issue. I think we need to revert the remaining non-compatible changes in Net 2.2, make a release, and then decide how to fix the NNTP code (which is only partially fixed at present anyway) without breaking compatibility. > - Jörg > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 1:15 PM, Jörg Schaible wrote: > > Do you also try 2.2-SNAPSHOT ? > > When I look at http://commons.apache.org/net/changes-report.html and > http://commons.apache.org/net/clirr-report.html it seems that 2.2 is again > not really binary compatible anymore. > It fails with the same message with 2.2-SNAPSHOT on the classpath. It's weird that the JDK-based classes work for this case, but not the net-based ones. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 1:18 PM, sebb wrote: > > It's not possible currently to compile the core code using Java 1.4. > > Since we ship source, I think this is a blocker. > And, it's easy to fix, so why not just cut a new RC? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
James Carman wrote: > On Fri, Nov 5, 2010 at 12:24 PM, James Carman > wrote: >> >> Interestingly enough, the program fails when I put net 1.4.1 on the >> classpath with: >> >> Exception in thread "main" >> org.apache.commons.vfs.FileNotFoundException: Could not read from >> "ftp://ftp.microsoft.com/MISC/CBCP.TXT"; because it is a not a file. >> at >> org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1281) >> at >> org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:394) >> at com.carmanconsulting.vfs.App.main(App.java:38) Caused by: >> java.io.FileNotFoundException: ftp://ftp.microsoft.com/MISC/CBCP.TXT at >> org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetInputStream(FtpFileObject.java:594) >> at >> org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1273) >> ... 2 more >> > > Of course, it also fails with net 2.0. Weird. >:D Do you also try 2.2-SNAPSHOT ? When I look at http://commons.apache.org/net/changes-report.html and http://commons.apache.org/net/clirr-report.html it seems that 2.2 is again not really binary compatible anymore. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 17:11, Jörg Schaible wrote: > Gary Gregory wrote: > >> One thing that drives me nuts is that most project do not list the JRE >> requirements on the front page of the project. It's not even in the >> project dependencies either. >> >> So we should at least update the docs IMO for Java 5. > > +1 > > Not a blocker though. > > However, it seems that the news section should have been really updated as > proposed: Minimum Java 1.4 (or 5 - depends on what we decide). It's not possible currently to compile the core code using Java 1.4. Since we ship source, I think this is a blocker. > > - Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 1:01 PM, sebb wrote: > > Why change package names? Surely the API is compatible? If not, then a > name change may be advisable even if staying with Java 1.4. > Seems reasonable to me, but the question to be asked is, why do we jump to 2.0 here? Is there really a revolutionary change going on? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release Commons VFS 2.0
Gary Gregory wrote: > One thing that drives me nuts is that most project do not list the JRE > requirements on the front page of the project. It's not even in the > project dependencies either. > > So we should at least update the docs IMO for Java 5. +1 Not a blocker though. However, it seems that the news section should have been really updated as proposed: Minimum Java 1.4 (or 5 - depends on what we decide). - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Ralph Goers wrote: > At this point is that just a web site change (post release)? Do we have > to change the package names and re-release? No. VFS itself is backward compatible, we cannot really check every time any dependency - even if it is another commons dependency. So site update is still enough. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 9:57 AM, sebb wrote: > On 5 November 2010 16:51, Ralph Goers wrote: >> >> On Nov 5, 2010, at 9:36 AM, James Carman wrote: >> >>> On Fri, Nov 5, 2010 at 12:30 PM, Jörg Schaible >>> wrote: As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 also? >>> >>> +1! Quit living in the past. Of course, we then have to discuss the >>> package name (and thus artifact id) change. :) >>> >> >> It seems we had that discussion before and agreed it was OK to jump to Java >> 5. http://www.mail-archive.com/dev@commons.apache.org/msg11705.html. I guess >> it was never formally done. I had planned on doing some refactoring that I >> quess I never got around to. >> >> Note that the minimum version for 1.0 was 1.3. Whoever started 2.0 changed >> the minimum version to 1.4. > > Are we referring to VFS or NET here? VFS - The 2.0 work was started before I got to Commons. > >> >> If package names change it will require a bit of work. I'm not sure there >> is anyone using 1.0. All the questions on the dev list have been for 2.0 for >> quite some time. > > Ditto - are we referring to VFS or NET here? > > I see no need to change package names if the API is compatible. VFS. To be honest, I've only glanced at 1.0. I'm not sure if they are compatible or not. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] "Smart" (aka auto-configure) pools
xfer to dev distro =) > On Nov 5, 2010, at 10:23 AM, James Carman > wrote: > > > On Fri, Nov 5, 2010 at 10:11 AM, Phil Steitz > wrote: > >> > >> The challenge with making a smart pool implementation is that it is hard > to > >> define an algorithm that "does no harm" (i.e. always actually improves > >> performance) can be fully documented and is at least tractable to > document, > >> maintain and support. That does not mean it is impossible and I am > >> interested in having a look at your ideas. > >> > > > > Why not set it up so that the algorithm could be "plugged in" instead > > of trying to come up with the end-all be-all solution? > > +1 > Agreed! > > > The trick is > > to make sure you capture all the metrics necessary for the plugged in > > strategy can make its decision(s). Or, you could do it another way. > > You could allow the implementation to track all of the stuff that it > > needs on its own. This way, you'd have to "publish" events for > > interested parties to subscribe to (object borrowed, object returned, > > object discarded, etc.) > > > +1 but it would probably be more convenient for users to be able to > hitchhike on the maintenance thread as Steve suggests to actually kick off > adjustments. Also, not just the pool but also object factories will need to > publish events. > > I think we might have a couple options for this...but since we're planning JMX instrumentation, perhaps we can leverage this to provide notifications/eventing back to the service. This way, we're still letting the maintenance thread do the work, it is just updating the MBean as it normally would. In this scenario, the "auto-manager" would use JMX to then modify the runtime configuration though the same methods it would expose via JMX. Thoughts? > We should probably take this discussion to the dev list at this point. > > Phil > > > - > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > For additional commands, e-mail: user-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > >
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 16:56, Ralph Goers wrote: > At this point is that just a web site change (post release)? Do we have to > change the package names and re-release? Why change package names? Surely the API is compatible? If not, then a name change may be advisable even if staying with Java 1.4. However, embedded docs (e.g. release notes) ought really to change. And I'm really not happy approving a release that includes the current LargeTar test implementation. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] FunctionEvaluationException in UnivariateRealFunction
Hi Gilles, - "Gilles Sadowski" a écrit : > Luc, > > > > [...] > > > > > > There are at least 2 different issues: > > > 1. What is the recommended behaviour of implementations > > > 2. What CM will do when it calls "value" and catches an exception > > > > There is a third issue, and it was a driver for the current > architecture. > > Some CM algorithms are utilities that are provided by the library > that > > act on low level user functions and are intended to be called from > higher > > level user function. They are "sandwiched" between two user levels. > Typical > > examples are root finding, optimization or ODE integrators. > > > > In this case, the user knows it's own function and the fact it can > fail for > > some values. When this case occurs, the function throws some kind of > exception > > so that the algorithm is interrupted. It does not simply return a > NaN as this would > > simply cause a nightmare in the commons math algorithms. The code > compiles only if > > the exception was authorized beforehand in the interface (this was > the case with the > > former architecture an checked exceptions) or if it is an unchecked > exception (which is > > the case now). Of course, the user could have thrown any other > unchecked exception > > even in the former architecture. At runtime, the commons-math > algorithm does not > > catch the exception, neither the checked one before nor the > unchecked one now (it may > > catch it, wrap it in its own exception and throw the wrapped one > again, but I don't > > remember any exemple of this behavior in commons-math, only in upper > level libraries > > I use). So some exception reached higher level user code, and there > the user can decide > > what to do with it. > > I completely agree with the above. Fine, thanks. > > > If the same development team does develop both user levels, > declaring exceptions could > > be cumbersome. If different development teams are in charge of the > low anf top level, > > it is interesting to have a way to convey development guidelines to > them via javadoc > > or declared throws statements. At least with one generic exception > like > > FunctionEvaluationException, we provide an hint to developers of the > low level function > > that it would be wise to stick with this exception type (even if > they want to wrap a > > NotPositiveException in it for the sake of better relevance). We > also provide an hint to > > developers of the top level algorithm that calls commons-math that > the function they > > provide to it and that was provided to them by the other team may > throw this exception > > and that commons-math simply let it slip upward. So they are aware > they should at least > > understand when this occurs and be able to act properly. > > From there I differ because your 3rd case is IMO outside of CM > business. > If CM let the exceptions propagate (which I'm all for), why bother > with it? Because we suggest users should use these exceptions. These are guidelines. > What do we gain in telling developers what they should do? It is clear > that > the upper and lower levels teams must communicate (probably through > documentation) but whatever they choose as exception doesn't affect CM We help build a common infrastructure or guidelines on which they can rely. Sometime, the teams do not even know each other, it may be impossible for them to communicate. But team LowA could say "hey, the CM guys suggest me to use a FunctionEvaluationException for my error, let's do that" and then team High would say "hey, it's good, on all our dependencies all teams LowA, lowB, ... and lowZ all choosed the recommended FunctionEvaluationException, it is much simpler for us to use their libraries. > at > all. I maintain that it is misleading to let them believe they should > stick > to "FunctionEvaluationException"; it's simply not true: this exception > or > another will just slip upward, as you said. Yes, and it is sad but unavoidable. Not a reason to not try to provide some guidelines. Some people say managing programmers is like herding cats, managing exceptions is the same. > > > > > > > For (1) I don't think that it is wise to suggest that any > function > > > should > > > throw "FunctionEvaluationException", because this exception > doesn't > > > convey > > > any information. For example, a function that will compute the > > > square-root > > > should better throw a more specific "NotPositiveException" (a > subclass > > > of > > > "IllegalArgumentException") when passed a negative argument. > > > > Yes, a more focused exception would be better. It is also possible > to > > wrap a focused NotPositiveException into a general > FunctionEvaluationException > > and get the best of both worlds. > > I don't think that it's the best of both, because the wrapping doesn't > serve > any purpose. It's true when everybody knows whats going on. It's false in a multi-team environment where its added value is to simplify work for
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 16:51, Ralph Goers wrote: > > On Nov 5, 2010, at 9:36 AM, James Carman wrote: > >> On Fri, Nov 5, 2010 at 12:30 PM, Jörg Schaible wrote: >>> >>> As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 >>> also? >>> >> >> +1! Quit living in the past. Of course, we then have to discuss the >> package name (and thus artifact id) change. :) >> > > It seems we had that discussion before and agreed it was OK to jump to Java > 5. http://www.mail-archive.com/dev@commons.apache.org/msg11705.html. I guess > it was never formally done. I had planned on doing some refactoring that I > quess I never got around to. > > Note that the minimum version for 1.0 was 1.3. Whoever started 2.0 changed > the minimum version to 1.4. Are we referring to VFS or NET here? > > If package names change it will require a bit of work. I'm not sure there is > anyone using 1.0. All the questions on the dev list have been for 2.0 for > quite some time. Ditto - are we referring to VFS or NET here? I see no need to change package names if the API is compatible. > > Ralph > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
At this point is that just a web site change (post release)? Do we have to change the package names and re-release? Ralph On Nov 5, 2010, at 9:45 AM, Henning Schmiedehausen wrote: > I like that idea. A lot. +1 > > -h > > On Fri, Nov 5, 2010 at 12:30, Jörg Schaible wrote: > >> As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 >> also? >> >> - Jörg >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 12:24 PM, James Carman wrote: > > Interestingly enough, the program fails when I put net 1.4.1 on the > classpath with: > > Exception in thread "main" > org.apache.commons.vfs.FileNotFoundException: Could not read from > "ftp://ftp.microsoft.com/MISC/CBCP.TXT"; because it is a not a file. > at > org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1281) > at > org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:394) > at com.carmanconsulting.vfs.App.main(App.java:38) > Caused by: java.io.FileNotFoundException: > ftp://ftp.microsoft.com/MISC/CBCP.TXT > at > org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetInputStream(FtpFileObject.java:594) > at > org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1273) > ... 2 more > Of course, it also fails with net 2.0. Weird. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 12:51 PM, Ralph Goers wrote: > > If package names change it will require a bit of work. I'm not sure there is > anyone using 1.0. All the questions on the dev list have been for 2.0 for > quite some time. > I'm using 1.x in our project I believe, but then again, I don't mind changing the package name in my code at all (since I write a utility class to "hide" all the checked exceptions). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release Commons VFS 2.0
> -Original Message- > From: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Sent: Friday, November 05, 2010 09:52 > To: Commons Developers List > Subject: Re: [VOTE] Release Commons VFS 2.0 > > > On Nov 5, 2010, at 9:36 AM, James Carman wrote: > > > On Fri, Nov 5, 2010 at 12:30 PM, Jörg Schaible > wrote: > >> > >> As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 > >> also? > >> > > > > +1! Quit living in the past. Of course, we then have to discuss the > > package name (and thus artifact id) change. :) > > > > It seems we had that discussion before and agreed it was OK to jump to Java 5. > http://www.mail-archive.com/dev@commons.apache.org/msg11705.html. I guess it > was never formally done. I had planned on doing some refactoring that I quess > I never got around to. > > Note that the minimum version for 1.0 was 1.3. Whoever started 2.0 changed the > minimum version to 1.4. > > If package names change it will require a bit of work. I'm not sure there is > anyone using 1.0. All the questions on the dev list have been for 2.0 for > quite some time. FYI: We've been shipping with 1.0 for a long time and plan on upgrading to 2.0. We require Java 6 for all our Java apps. Gary > > Ralph > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 16:50, Gary Gregory wrote: > One thing that drives me nuts is that most project do not list the JRE > requirements on the front page of the project. It's not even in the project > dependencies either. My thoughts exactly. > So we should at least update the docs IMO for Java 5. +1 > Gary > > >> -Original Message- >> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org] >> Sent: Friday, November 05, 2010 09:47 >> To: Commons Developers List >> Subject: Re: [VOTE] Release Commons VFS 2.0 >> >> I read all the concerns and comments and I believe that the >> commons-net thing is a documentation issue. People who still use Java >> 1.4 today should probably know what they do when they upgrade a major >> version changed new release of an API. >> >> So my vote is +1 to release VFS as tagged and put there. >> >> -h >> >> >> >> On Thu, Nov 4, 2010 at 23:05, Ralph Goers wrote: >> > This is a vote to release Apache Commons VFS 2.0. >> > >> > [ ] +1 release it >> > [ ] +0 go ahead I don't care >> > [ ] -1 no, do not release it because... >> > >> > Ralph >> > >> > tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >> project-2.0/ >> > >> > site: http://people.apache.org/~rgoers/commons-vfs/index.html >> > >> > The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >> > >> > >> > commons-vfs-examples-2.0.jar.asc >> > commons-vfs-examples-2.0-javadoc.jar.asc >> > commons-vfs-examples-2.0.pom.asc >> > commons-vfs-examples-2.0.jar >> > commons-vfs-examples-2.0.pom >> > commons-vfs-examples-2.0-sources.jar >> > commons-vfs-examples-2.0-sources.jar.asc >> > commons-vfs-examples-2.0-javadoc.jar >> > commons-vfs-distribution-2.0.pom >> > commons-vfs-distribution-2.0-src.tar.gz >> > commons-vfs-distribution-2.0-bin.zip >> > commons-vfs-distribution-2.0-src.tar.gz.asc >> > commons-vfs-distribution-2.0.pom.asc >> > commons-vfs-distribution-2.0-src.zip.asc >> > commons-vfs-distribution-2.0-src.zip >> > commons-vfs-distribution-2.0-bin.tar.gz.asc >> > commons-vfs-distribution-2.0-bin.tar.gz >> > commons-vfs-distribution-2.0-bin.zip.asc >> > commons-vfs-sandbox-2.0-sources.jar.asc >> > commons-vfs-sandbox-2.0-sources.jar >> > commons-vfs-sandbox-2.0.jar >> > commons-vfs-sandbox-2.0.jar.asc >> > commons-vfs-sandbox-2.0.pom >> > commons-vfs-sandbox-2.0-tests.jar.asc >> > commons-vfs-sandbox-2.0-tests.jar >> > commons-vfs-sandbox-2.0-javadoc.jar.asc >> > commons-vfs-sandbox-2.0-test-sources.jar.asc >> > commons-vfs-sandbox-2.0.pom.asc >> > commons-vfs-sandbox-2.0-javadoc.jar >> > commons-vfs-sandbox-2.0-test-sources.jar >> > commons-vfs-2.0-test-sources.jar >> > commons-vfs-2.0-sources.jar.asc >> > commons-vfs-2.0-tests.jar.asc >> > commons-vfs-2.0-tests.jar >> > commons-vfs-2.0-javadoc.jar >> > commons-vfs-2.0-test-sources.jar.asc >> > commons-vfs-2.0.pom >> > commons-vfs-2.0-javadoc.jar.asc >> > commons-vfs-2.0.jar >> > commons-vfs-2.0.jar.asc >> > commons-vfs-2.0-sources.jar >> > commons-vfs-2.0.pom.asc >> > commons-vfs-project-2.0-site.xml.asc >> > commons-vfs-project-2.0.pom >> > commons-vfs-project-2.0-site.xml >> > commons-vfs-project-2.0.pom.asc >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 9:36 AM, James Carman wrote: > On Fri, Nov 5, 2010 at 12:30 PM, Jörg Schaible wrote: >> >> As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 >> also? >> > > +1! Quit living in the past. Of course, we then have to discuss the > package name (and thus artifact id) change. :) > It seems we had that discussion before and agreed it was OK to jump to Java 5. http://www.mail-archive.com/dev@commons.apache.org/msg11705.html. I guess it was never formally done. I had planned on doing some refactoring that I quess I never got around to. Note that the minimum version for 1.0 was 1.3. Whoever started 2.0 changed the minimum version to 1.4. If package names change it will require a bit of work. I'm not sure there is anyone using 1.0. All the questions on the dev list have been for 2.0 for quite some time. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 16:43, James Carman wrote: > On Fri, Nov 5, 2010 at 12:28 PM, Ralph Goers > wrote: >>> >>> If NET 2.0 is truly optional, then it is not a blocker so long as it >>> is clearly documented. >>> >>> I assume that NET 2.0 was added in order to support FTPS? >> >> I have no idea. You did the update from 1.4.1 to 2.0 in 999496 on 09/21/10. >> The support for FTPS was added in 993534 by jcarman on 09/0710. >> > > FTPS support was added to the 2.0 release of Commons Net per the > release notes. I guess the patch I applied from the JIRA issue didn't > bump the dependency from 1.4.1 to 2.x, so he was probably fixing my > screw up (thanks sebb). Sort of - see my reply else-thread. > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release Commons VFS 2.0
One thing that drives me nuts is that most project do not list the JRE requirements on the front page of the project. It's not even in the project dependencies either. So we should at least update the docs IMO for Java 5. Gary > -Original Message- > From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org] > Sent: Friday, November 05, 2010 09:47 > To: Commons Developers List > Subject: Re: [VOTE] Release Commons VFS 2.0 > > I read all the concerns and comments and I believe that the > commons-net thing is a documentation issue. People who still use Java > 1.4 today should probably know what they do when they upgrade a major > version changed new release of an API. > > So my vote is +1 to release VFS as tagged and put there. > > -h > > > > On Thu, Nov 4, 2010 at 23:05, Ralph Goers wrote: > > This is a vote to release Apache Commons VFS 2.0. > > > > [ ] +1 release it > > [ ] +0 go ahead I don't care > > [ ] -1 no, do not release it because... > > > > Ralph > > > > tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- > project-2.0/ > > > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > > > The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) > > > > > > commons-vfs-examples-2.0.jar.asc > > commons-vfs-examples-2.0-javadoc.jar.asc > > commons-vfs-examples-2.0.pom.asc > > commons-vfs-examples-2.0.jar > > commons-vfs-examples-2.0.pom > > commons-vfs-examples-2.0-sources.jar > > commons-vfs-examples-2.0-sources.jar.asc > > commons-vfs-examples-2.0-javadoc.jar > > commons-vfs-distribution-2.0.pom > > commons-vfs-distribution-2.0-src.tar.gz > > commons-vfs-distribution-2.0-bin.zip > > commons-vfs-distribution-2.0-src.tar.gz.asc > > commons-vfs-distribution-2.0.pom.asc > > commons-vfs-distribution-2.0-src.zip.asc > > commons-vfs-distribution-2.0-src.zip > > commons-vfs-distribution-2.0-bin.tar.gz.asc > > commons-vfs-distribution-2.0-bin.tar.gz > > commons-vfs-distribution-2.0-bin.zip.asc > > commons-vfs-sandbox-2.0-sources.jar.asc > > commons-vfs-sandbox-2.0-sources.jar > > commons-vfs-sandbox-2.0.jar > > commons-vfs-sandbox-2.0.jar.asc > > commons-vfs-sandbox-2.0.pom > > commons-vfs-sandbox-2.0-tests.jar.asc > > commons-vfs-sandbox-2.0-tests.jar > > commons-vfs-sandbox-2.0-javadoc.jar.asc > > commons-vfs-sandbox-2.0-test-sources.jar.asc > > commons-vfs-sandbox-2.0.pom.asc > > commons-vfs-sandbox-2.0-javadoc.jar > > commons-vfs-sandbox-2.0-test-sources.jar > > commons-vfs-2.0-test-sources.jar > > commons-vfs-2.0-sources.jar.asc > > commons-vfs-2.0-tests.jar.asc > > commons-vfs-2.0-tests.jar > > commons-vfs-2.0-javadoc.jar > > commons-vfs-2.0-test-sources.jar.asc > > commons-vfs-2.0.pom > > commons-vfs-2.0-javadoc.jar.asc > > commons-vfs-2.0.jar > > commons-vfs-2.0.jar.asc > > commons-vfs-2.0-sources.jar > > commons-vfs-2.0.pom.asc > > commons-vfs-project-2.0-site.xml.asc > > commons-vfs-project-2.0.pom > > commons-vfs-project-2.0-site.xml > > commons-vfs-project-2.0.pom.asc > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 16:28, Ralph Goers wrote: > > On Nov 5, 2010, at 9:10 AM, sebb wrote: > >> On 5 November 2010 15:30, Ralph Goers wrote: >>> >>> On Nov 5, 2010, at 2:49 AM, sebb wrote: >>> On 5 November 2010 03:05, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [X] -1 no, do not release it because... The code has a dependency on Commons NET 2.0, which requires Java 1.5+ However VFS targets Java 1.4+ >>> >>> Do you really consider this to be a -1? I consider this to be a >>> documentation issue. User's can pick and choose which providers they want >>> and simply need to be aware that Net 2.0 requires 1.5. >> >> If NET 2.0 is truly optional, then it is not a blocker so long as it >> is clearly documented. >> >> I assume that NET 2.0 was added in order to support FTPS? > > I have no idea. You did the update from 1.4.1 to 2.0 in 999496 on 09/21/10. Not quite. The code was already dependent on 2.0 in core/pom.xml. What I did was move the 2.0 version from core/pom.xml to ./pom.xml to avoid having both 1.4.1 and 2.0 as dependencies. > The support for FTPS was added in 993534 by jcarman on 09/0710. Which is when Net 2.0 was added to core/pom.xml > >> >> If so, what about someone using Java 1.4 - can they update to VFS 2.0, >> but keep the FTP support from NET 1.4? >> Or will they lose FTP support entirely? > > Both FTP and FTPS look for the presence of > org.apache.commons.net.ftp.FTPFile. I would assume that in a Java 1.4 system > Net 2.0 would cause a wrong version error when the jar is loaded. VFS is > looking for a ClassNotFoundException to determine whether the dependency is > present. I don't recall what exception/error is thrown when the version is > wrong. > > Ralph > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release Commons VFS 2.0
> -Original Message- > From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org] > Sent: Friday, November 05, 2010 09:46 > To: Commons Developers List; joerg.schai...@gmx.de > Subject: Re: [VOTE] Release Commons VFS 2.0 > > I like that idea. A lot. +1 > > -h > > On Fri, Nov 5, 2010 at 12:30, Jörg Schaible wrote: > > > As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 > > also? For a major release bump, that seems reasonable. Gary > > > > - Jörg > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
I read all the concerns and comments and I believe that the commons-net thing is a documentation issue. People who still use Java 1.4 today should probably know what they do when they upgrade a major version changed new release of an API. So my vote is +1 to release VFS as tagged and put there. -h On Thu, Nov 4, 2010 at 23:05, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... > > Ralph > > tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) > > > commons-vfs-examples-2.0.jar.asc > commons-vfs-examples-2.0-javadoc.jar.asc > commons-vfs-examples-2.0.pom.asc > commons-vfs-examples-2.0.jar > commons-vfs-examples-2.0.pom > commons-vfs-examples-2.0-sources.jar > commons-vfs-examples-2.0-sources.jar.asc > commons-vfs-examples-2.0-javadoc.jar > commons-vfs-distribution-2.0.pom > commons-vfs-distribution-2.0-src.tar.gz > commons-vfs-distribution-2.0-bin.zip > commons-vfs-distribution-2.0-src.tar.gz.asc > commons-vfs-distribution-2.0.pom.asc > commons-vfs-distribution-2.0-src.zip.asc > commons-vfs-distribution-2.0-src.zip > commons-vfs-distribution-2.0-bin.tar.gz.asc > commons-vfs-distribution-2.0-bin.tar.gz > commons-vfs-distribution-2.0-bin.zip.asc > commons-vfs-sandbox-2.0-sources.jar.asc > commons-vfs-sandbox-2.0-sources.jar > commons-vfs-sandbox-2.0.jar > commons-vfs-sandbox-2.0.jar.asc > commons-vfs-sandbox-2.0.pom > commons-vfs-sandbox-2.0-tests.jar.asc > commons-vfs-sandbox-2.0-tests.jar > commons-vfs-sandbox-2.0-javadoc.jar.asc > commons-vfs-sandbox-2.0-test-sources.jar.asc > commons-vfs-sandbox-2.0.pom.asc > commons-vfs-sandbox-2.0-javadoc.jar > commons-vfs-sandbox-2.0-test-sources.jar > commons-vfs-2.0-test-sources.jar > commons-vfs-2.0-sources.jar.asc > commons-vfs-2.0-tests.jar.asc > commons-vfs-2.0-tests.jar > commons-vfs-2.0-javadoc.jar > commons-vfs-2.0-test-sources.jar.asc > commons-vfs-2.0.pom > commons-vfs-2.0-javadoc.jar.asc > commons-vfs-2.0.jar > commons-vfs-2.0.jar.asc > commons-vfs-2.0-sources.jar > commons-vfs-2.0.pom.asc > commons-vfs-project-2.0-site.xml.asc > commons-vfs-project-2.0.pom > commons-vfs-project-2.0-site.xml > commons-vfs-project-2.0.pom.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
I like that idea. A lot. +1 -h On Fri, Nov 5, 2010 at 12:30, Jörg Schaible wrote: > As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 > also? > > - Jörg > > > - > 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: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integratio
> > > > > > I don't know if it's relevant here, but it's standard practice in > > lots > > > of code I've seen to document unchecked exceptions in the @throws > > > block if your code explicitly throws it. > > > > This would be the minimum, but it seems that CM tries to be better in > > that > > it aims at also documenting the exceptions thrown from the called > > code. > > No. We try to explain what the user could throw or rather provide guidelines > on what to throw. Luc, My sentence had nothing to do with user code. It is a compliment about CM trying to fully document its own code, including the exceptions that could be thrown from CM methods called be other CM methods. This is indeed invaluable help because there is no other way (short of reading the source code) for a user to know what to expect from one level deeper than the methods he directly calls. > > Of course it is more work on the part of the developer and also more > > difficult do check for consistency when reading the code (short of > > following > > all the calls). > > Yes, and it what I like in checked exception, [...] It doesn't help because unchecked exceptions exist! If only checked exception existed, then yes, self-consistency could be achieved easily. Best, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 12:28 PM, Ralph Goers wrote: >> >> If NET 2.0 is truly optional, then it is not a blocker so long as it >> is clearly documented. >> >> I assume that NET 2.0 was added in order to support FTPS? > > I have no idea. You did the update from 1.4.1 to 2.0 in 999496 on 09/21/10. > The support for FTPS was added in 993534 by jcarman on 09/0710. > FTPS support was added to the 2.0 release of Commons Net per the release notes. I guess the patch I applied from the JIRA issue didn't bump the dependency from 1.4.1 to 2.x, so he was probably fixing my screw up (thanks sebb). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
I disagree with this. The tests run a little but almost no one will ever run them. Shipping a 3MB file that is used with one test in the whole distribution seems to be a waste of space and bandwidth for everyone else. -h On Fri, Nov 5, 2010 at 06:03, sebb wrote: > On 5 November 2010 09:49, sebb wrote: >> On 5 November 2010 03:05, Ralph Goers wrote: >>> This is a vote to release Apache Commons VFS 2.0. >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [X] -1 no, do not release it because... >> >> The code has a dependency on Commons NET 2.0, which requires Java 1.5+ >> However VFS targets Java 1.4+ >> >> >> Note: this was found by running the following Maven command: >> >> mvn package -Pjava-1.4 >> >> The test is very noisy - not sure it's useful to have the following >> lines printed: >> >> skipping testDeleteOneFiles because TarFileSystem does not have >> capability CREATE >> >> Also, I think LargeTarTestCase should be optional (or ideally be >> rewritten to not need so much disk space - not sure that is possible). > > Given that the tgz version of the file is 'only' 3MB, maybe that could > just be included as a test resource? > That would save time creating it, and might avoid the need to depend > on Compress. > >> >> The source package still contains the DOAP file (not a blocker). >> >>> >>> Ralph >>> >>> tag: >>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >>> >>> site: http://people.apache.org/~rgoers/commons-vfs/index.html >>> >>> The following artifacts have been staged to the Apache Nexus Staging >>> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >>> >>> >>> commons-vfs-examples-2.0.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar.asc >>> commons-vfs-examples-2.0.pom.asc >>> commons-vfs-examples-2.0.jar >>> commons-vfs-examples-2.0.pom >>> commons-vfs-examples-2.0-sources.jar >>> commons-vfs-examples-2.0-sources.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar >>> commons-vfs-distribution-2.0.pom >>> commons-vfs-distribution-2.0-src.tar.gz >>> commons-vfs-distribution-2.0-bin.zip >>> commons-vfs-distribution-2.0-src.tar.gz.asc >>> commons-vfs-distribution-2.0.pom.asc >>> commons-vfs-distribution-2.0-src.zip.asc >>> commons-vfs-distribution-2.0-src.zip >>> commons-vfs-distribution-2.0-bin.tar.gz.asc >>> commons-vfs-distribution-2.0-bin.tar.gz >>> commons-vfs-distribution-2.0-bin.zip.asc >>> commons-vfs-sandbox-2.0-sources.jar.asc >>> commons-vfs-sandbox-2.0-sources.jar >>> commons-vfs-sandbox-2.0.jar >>> commons-vfs-sandbox-2.0.jar.asc >>> commons-vfs-sandbox-2.0.pom >>> commons-vfs-sandbox-2.0-tests.jar.asc >>> commons-vfs-sandbox-2.0-tests.jar >>> commons-vfs-sandbox-2.0-javadoc.jar.asc >>> commons-vfs-sandbox-2.0-test-sources.jar.asc >>> commons-vfs-sandbox-2.0.pom.asc >>> commons-vfs-sandbox-2.0-javadoc.jar >>> commons-vfs-sandbox-2.0-test-sources.jar >>> commons-vfs-2.0-test-sources.jar >>> commons-vfs-2.0-sources.jar.asc >>> commons-vfs-2.0-tests.jar.asc >>> commons-vfs-2.0-tests.jar >>> commons-vfs-2.0-javadoc.jar >>> commons-vfs-2.0-test-sources.jar.asc >>> commons-vfs-2.0.pom >>> commons-vfs-2.0-javadoc.jar.asc >>> commons-vfs-2.0.jar >>> commons-vfs-2.0.jar.asc >>> commons-vfs-2.0-sources.jar >>> commons-vfs-2.0.pom.asc >>> commons-vfs-project-2.0-site.xml.asc >>> commons-vfs-project-2.0.pom >>> commons-vfs-project-2.0-site.xml >>> commons-vfs-project-2.0.pom.asc >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
I disagree that this is a blocker. This *might* be a documentation issue that the FTP and FTPS providers require Java 1.5. Everything else is just fine and usable. On a side note: Everything but Java 6 has been EOLed. I would be perfectly cool for all new components to be implicit "runs only on Java 6 and beyond. If you use something older, don't upgrade". -h On Fri, Nov 5, 2010 at 06:03, sebb wrote: > On 5 November 2010 09:49, sebb wrote: >> On 5 November 2010 03:05, Ralph Goers wrote: >>> This is a vote to release Apache Commons VFS 2.0. >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [X] -1 no, do not release it because... >> >> The code has a dependency on Commons NET 2.0, which requires Java 1.5+ >> However VFS targets Java 1.4+ >> >> >> Note: this was found by running the following Maven command: >> >> mvn package -Pjava-1.4 >> >> The test is very noisy - not sure it's useful to have the following >> lines printed: >> >> skipping testDeleteOneFiles because TarFileSystem does not have >> capability CREATE >> >> Also, I think LargeTarTestCase should be optional (or ideally be >> rewritten to not need so much disk space - not sure that is possible). > > Given that the tgz version of the file is 'only' 3MB, maybe that could > just be included as a test resource? > That would save time creating it, and might avoid the need to depend > on Compress. > >> >> The source package still contains the DOAP file (not a blocker). >> >>> >>> Ralph >>> >>> tag: >>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >>> >>> site: http://people.apache.org/~rgoers/commons-vfs/index.html >>> >>> The following artifacts have been staged to the Apache Nexus Staging >>> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >>> >>> >>> commons-vfs-examples-2.0.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar.asc >>> commons-vfs-examples-2.0.pom.asc >>> commons-vfs-examples-2.0.jar >>> commons-vfs-examples-2.0.pom >>> commons-vfs-examples-2.0-sources.jar >>> commons-vfs-examples-2.0-sources.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar >>> commons-vfs-distribution-2.0.pom >>> commons-vfs-distribution-2.0-src.tar.gz >>> commons-vfs-distribution-2.0-bin.zip >>> commons-vfs-distribution-2.0-src.tar.gz.asc >>> commons-vfs-distribution-2.0.pom.asc >>> commons-vfs-distribution-2.0-src.zip.asc >>> commons-vfs-distribution-2.0-src.zip >>> commons-vfs-distribution-2.0-bin.tar.gz.asc >>> commons-vfs-distribution-2.0-bin.tar.gz >>> commons-vfs-distribution-2.0-bin.zip.asc >>> commons-vfs-sandbox-2.0-sources.jar.asc >>> commons-vfs-sandbox-2.0-sources.jar >>> commons-vfs-sandbox-2.0.jar >>> commons-vfs-sandbox-2.0.jar.asc >>> commons-vfs-sandbox-2.0.pom >>> commons-vfs-sandbox-2.0-tests.jar.asc >>> commons-vfs-sandbox-2.0-tests.jar >>> commons-vfs-sandbox-2.0-javadoc.jar.asc >>> commons-vfs-sandbox-2.0-test-sources.jar.asc >>> commons-vfs-sandbox-2.0.pom.asc >>> commons-vfs-sandbox-2.0-javadoc.jar >>> commons-vfs-sandbox-2.0-test-sources.jar >>> commons-vfs-2.0-test-sources.jar >>> commons-vfs-2.0-sources.jar.asc >>> commons-vfs-2.0-tests.jar.asc >>> commons-vfs-2.0-tests.jar >>> commons-vfs-2.0-javadoc.jar >>> commons-vfs-2.0-test-sources.jar.asc >>> commons-vfs-2.0.pom >>> commons-vfs-2.0-javadoc.jar.asc >>> commons-vfs-2.0.jar >>> commons-vfs-2.0.jar.asc >>> commons-vfs-2.0-sources.jar >>> commons-vfs-2.0.pom.asc >>> commons-vfs-project-2.0-site.xml.asc >>> commons-vfs-project-2.0.pom >>> commons-vfs-project-2.0-site.xml >>> commons-vfs-project-2.0.pom.asc >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 12:30 PM, Jörg Schaible wrote: > > As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 > also? > +1! Quit living in the past. Of course, we then have to discuss the package name (and thus artifact id) change. :) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integratio
- "Gilles Sadowski" a écrit : > Hello. > > > >> So go ahead with the change, removing the throws from the > declaration but keeping the javadoc as suggested previously. > > > > > > Again, what is it that you try to convey by specifying a single > exception in > > > the Javadoc? Any unchecked exception can be thrown from a class > that > > > implement the interface. > > > If the user code doesn't care that the evaluation fails, it should > catch > > > everything and continue. Alternatively, if it cannot continue, it > should let > > > the exception propagate. In either case, there isn't any useful > information > > > from a Javadoc "@throws" tag: We already know that unchecked > exceptions can > > > arise. > > > > I don't know if it's relevant here, but it's standard practice in > lots > > of code I've seen to document unchecked exceptions in the @throws > > block if your code explicitly throws it. > > This would be the minimum, but it seems that CM tries to be better in > that > it aims at also documenting the exceptions thrown from the called > code. No. We try to explain what the user could throw or rather provide guidelines on what to throw. > Of course it is more work on the part of the developer and also more > difficult do check for consistency when reading the code (short of > following > all the calls). Yes, and it what I like in checked exception, but I will not come back to this discussion, now we use unchecked exception, so we document them. Luc > > > However I would not put this > > tag on the interface method declaration, because maybe some > > implementation doesn't throw that exception. [...] > > +1 > > > Best, > Gilles > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Ralph Goers wrote: > > On Nov 5, 2010, at 8:51 AM, Jörg Schaible wrote: > >> Hi James, >> >> James Carman wrote: >> >>> On Fri, Nov 5, 2010 at 11:30 AM, Ralph Goers >>> wrote: Do you really consider this to be a -1? I consider this to be a documentation issue. User's can pick and choose which providers they want and simply need to be aware that Net 2.0 requires 1.5. >>> >>> The providers are auto-registered based on what's on the classpath. >>> So, if they added net 2.0 to their classpath, that provider would be >>> registered. It may not be completely obvious that net 2.0 requires >>> 1.5+. >> >> This is not the point. If they add net 2.0 to the classpath they are >> using Java 5 probably anyway. The interesting quesiton is, what happens >> if net 1.4 is on the classpath? I'd guess the provider is also >> auto-registered, but will crash at some point ... >> >>> I agree this is probably just a documentation issue. Don't >>> know if it should be a blocker. >> >> If the application will crash, just because net 1.4 is on the classpath, >> it is a blocker. If an application can run as logn as it does not use the >> stuff requiring net 2.0, it's unfortunate, but documentation is enough. > > I would have expected causing an application to crash because 1.4 is on > the classpath would have been a blocker to the net 2.0 release, not a > blocker for something using commons net. If VFS uses functionality only available in net-2.0, it's not net-2.0s fault. > Were incompatible API changes > made or just the bump in the minimum JVM? http://article.gmane.org/gmane.comp.jakarta.commons.devel/88018 It seems that some classes had been moved. Rereading the discussion in the thread it was supposed to be a "different code line". Why the recommendation to use a different package name was not followed, I could not find in the archives for now, but we're bitten now by this decision from 4 years ago ... As alternative: Can't we simply raise the minimum JDK level for VFS to 1.5 also? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 9:10 AM, sebb wrote: > On 5 November 2010 15:30, Ralph Goers wrote: >> >> On Nov 5, 2010, at 2:49 AM, sebb wrote: >> >>> On 5 November 2010 03:05, Ralph Goers wrote: This is a vote to release Apache Commons VFS 2.0. [ ] +1 release it [ ] +0 go ahead I don't care [X] -1 no, do not release it because... >>> >>> The code has a dependency on Commons NET 2.0, which requires Java 1.5+ >>> However VFS targets Java 1.4+ >> >> Do you really consider this to be a -1? I consider this to be a >> documentation issue. User's can pick and choose which providers they want >> and simply need to be aware that Net 2.0 requires 1.5. > > If NET 2.0 is truly optional, then it is not a blocker so long as it > is clearly documented. > > I assume that NET 2.0 was added in order to support FTPS? I have no idea. You did the update from 1.4.1 to 2.0 in 999496 on 09/21/10. The support for FTPS was added in 993534 by jcarman on 09/0710. > > If so, what about someone using Java 1.4 - can they update to VFS 2.0, > but keep the FTP support from NET 1.4? > Or will they lose FTP support entirely? Both FTP and FTPS look for the presence of org.apache.commons.net.ftp.FTPFile. I would assume that in a Java 1.4 system Net 2.0 would cause a wrong version error when the jar is loaded. VFS is looking for a ClassNotFoundException to determine whether the dependency is present. I don't recall what exception/error is thrown when the version is wrong. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 12:22 PM, James Carman wrote: > > FTP support works without Net at all. I just ran a test client and > excluded anything but the "core" from the classpath. It used the > org.apache.commons.vfs.provider.url.UrlFileSystem to handle FTP URLs. Interestingly enough, the program fails when I put net 1.4.1 on the classpath with: Exception in thread "main" org.apache.commons.vfs.FileNotFoundException: Could not read from "ftp://ftp.microsoft.com/MISC/CBCP.TXT"; because it is a not a file. at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1281) at org.apache.commons.vfs.provider.DefaultFileContent.getInputStream(DefaultFileContent.java:394) at com.carmanconsulting.vfs.App.main(App.java:38) Caused by: java.io.FileNotFoundException: ftp://ftp.microsoft.com/MISC/CBCP.TXT at org.apache.commons.vfs.provider.ftp.FtpFileObject.doGetInputStream(FtpFileObject.java:594) at org.apache.commons.vfs.provider.AbstractFileObject.getInputStream(AbstractFileObject.java:1273) ... 2 more - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 12:10 PM, sebb wrote:
> If so, what about someone using Java 1.4 - can they update to VFS 2.0,
> but keep the FTP support from NET 1.4?
> Or will they lose FTP support entirely?
>
FTP support works without Net at all. I just ran a test client and
excluded anything but the "core" from the classpath. It used the
org.apache.commons.vfs.provider.url.UrlFileSystem to handle FTP URLs.
Here's the code (from a user's question posted a while back):
String fileName = "CBCP.TXT";
FileSystemManager fsManager;
fsManager = VFS.getManager();
UserAuthenticator auth = new StaticUserAuthenticator(null,
"anonymous", "");
FileSystemOptions srcOpts = new FileSystemOptions();
String sourceDirAsString = "ftp://ftp.microsoft.com:21/MISC";;
DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(srcOpts,
auth);
FileObject sourceDir = fsManager.resolveFile(sourceDirAsString,
srcOpts); // HERE IS A HANG UP
FileObject neededFile = sourceDir.resolveFile(fileName);
System.out.println("Using file system type " +
neededFile.getFileSystem().getClass().getName() + "...");
FileContent content = neededFile.getContent();
byte[] buffer = new byte[1024];
final InputStream in = content.getInputStream();
int totalBytes = 0;
int bytesRead;
while((bytesRead = in.read(buffer)) != -1)
{
totalBytes += bytesRead;
}
System.out.println("Read " + totalBytes + " bytes from file of
size " + content.getSize());
Here's my pom.xml:
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.carmanconsulting.vfs
vfs-ftp
1.0-SNAPSHOT
jar
UTF-8
org.apache.commons
commons-vfs
2.0-SNAPSHOT
log4j
log4j
1.2.16
junit
junit
3.8.1
test
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 15:30, Ralph Goers wrote: > > On Nov 5, 2010, at 2:49 AM, sebb wrote: > >> On 5 November 2010 03:05, Ralph Goers wrote: >>> This is a vote to release Apache Commons VFS 2.0. >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [X] -1 no, do not release it because... >> >> The code has a dependency on Commons NET 2.0, which requires Java 1.5+ >> However VFS targets Java 1.4+ > > Do you really consider this to be a -1? I consider this to be a > documentation issue. User's can pick and choose which providers they want > and simply need to be aware that Net 2.0 requires 1.5. If NET 2.0 is truly optional, then it is not a blocker so long as it is clearly documented. I assume that NET 2.0 was added in order to support FTPS? If so, what about someone using Java 1.4 - can they update to VFS 2.0, but keep the FTP support from NET 1.4? Or will they lose FTP support entirely? > >> >> >> Note: this was found by running the following Maven command: >> >> mvn package -Pjava-1.4 >> >> The test is very noisy - not sure it's useful to have the following >> lines printed: >> >> skipping testDeleteOneFiles because TarFileSystem does not have >> capability CREATE >> >> Also, I think LargeTarTestCase should be optional (or ideally be >> rewritten to not need so much disk space - not sure that is possible). >> >> >> The source package still contains the DOAP file (not a blocker). >> >>> >>> Ralph >>> >>> tag: >>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >>> >>> site: http://people.apache.org/~rgoers/commons-vfs/index.html >>> >>> The following artifacts have been staged to the Apache Nexus Staging >>> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >>> >>> >>> commons-vfs-examples-2.0.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar.asc >>> commons-vfs-examples-2.0.pom.asc >>> commons-vfs-examples-2.0.jar >>> commons-vfs-examples-2.0.pom >>> commons-vfs-examples-2.0-sources.jar >>> commons-vfs-examples-2.0-sources.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar >>> commons-vfs-distribution-2.0.pom >>> commons-vfs-distribution-2.0-src.tar.gz >>> commons-vfs-distribution-2.0-bin.zip >>> commons-vfs-distribution-2.0-src.tar.gz.asc >>> commons-vfs-distribution-2.0.pom.asc >>> commons-vfs-distribution-2.0-src.zip.asc >>> commons-vfs-distribution-2.0-src.zip >>> commons-vfs-distribution-2.0-bin.tar.gz.asc >>> commons-vfs-distribution-2.0-bin.tar.gz >>> commons-vfs-distribution-2.0-bin.zip.asc >>> commons-vfs-sandbox-2.0-sources.jar.asc >>> commons-vfs-sandbox-2.0-sources.jar >>> commons-vfs-sandbox-2.0.jar >>> commons-vfs-sandbox-2.0.jar.asc >>> commons-vfs-sandbox-2.0.pom >>> commons-vfs-sandbox-2.0-tests.jar.asc >>> commons-vfs-sandbox-2.0-tests.jar >>> commons-vfs-sandbox-2.0-javadoc.jar.asc >>> commons-vfs-sandbox-2.0-test-sources.jar.asc >>> commons-vfs-sandbox-2.0.pom.asc >>> commons-vfs-sandbox-2.0-javadoc.jar >>> commons-vfs-sandbox-2.0-test-sources.jar >>> commons-vfs-2.0-test-sources.jar >>> commons-vfs-2.0-sources.jar.asc >>> commons-vfs-2.0-tests.jar.asc >>> commons-vfs-2.0-tests.jar >>> commons-vfs-2.0-javadoc.jar >>> commons-vfs-2.0-test-sources.jar.asc >>> commons-vfs-2.0.pom >>> commons-vfs-2.0-javadoc.jar.asc >>> commons-vfs-2.0.jar >>> commons-vfs-2.0.jar.asc >>> commons-vfs-2.0-sources.jar >>> commons-vfs-2.0.pom.asc >>> commons-vfs-project-2.0-site.xml.asc >>> commons-vfs-project-2.0.pom >>> commons-vfs-project-2.0-site.xml >>> commons-vfs-project-2.0.pom.asc >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 8:51 AM, Jörg Schaible wrote: > Hi James, > > James Carman wrote: > >> On Fri, Nov 5, 2010 at 11:30 AM, Ralph Goers >> wrote: >>> >>> Do you really consider this to be a -1? I consider this to be a >>> documentation issue. User's can pick and choose which providers they >>> want and simply need to be aware that Net 2.0 requires 1.5. >>> >> >> The providers are auto-registered based on what's on the classpath. >> So, if they added net 2.0 to their classpath, that provider would be >> registered. It may not be completely obvious that net 2.0 requires >> 1.5+. > > This is not the point. If they add net 2.0 to the classpath they are using > Java 5 probably anyway. The interesting quesiton is, what happens if net 1.4 > is on the classpath? I'd guess the provider is also auto-registered, but > will crash at some point ... > >> I agree this is probably just a documentation issue. Don't >> know if it should be a blocker. > > If the application will crash, just because net 1.4 is on the classpath, it > is a blocker. If an application can run as logn as it does not use the stuff > requiring net 2.0, it's unfortunate, but documentation is enough. I would have expected causing an application to crash because 1.4 is on the classpath would have been a blocker to the net 2.0 release, not a blocker for something using commons net. Were incompatible API changes made or just the bump in the minimum JVM? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 11:51 AM, Jörg Schaible wrote: > > This is not the point. If they add net 2.0 to the classpath they are using > Java 5 probably anyway. The interesting quesiton is, what happens if net 1.4 > is on the classpath? I'd guess the provider is also auto-registered, but > will crash at some point ... > Perhaps net 2.0 should have changed its package name to avoid this situation? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
Hi James, James Carman wrote: > On Fri, Nov 5, 2010 at 11:30 AM, Ralph Goers > wrote: >> >> Do you really consider this to be a -1? I consider this to be a >> documentation issue. User's can pick and choose which providers they >> want and simply need to be aware that Net 2.0 requires 1.5. >> > > The providers are auto-registered based on what's on the classpath. > So, if they added net 2.0 to their classpath, that provider would be > registered. It may not be completely obvious that net 2.0 requires > 1.5+. This is not the point. If they add net 2.0 to the classpath they are using Java 5 probably anyway. The interesting quesiton is, what happens if net 1.4 is on the classpath? I'd guess the provider is also auto-registered, but will crash at some point ... > I agree this is probably just a documentation issue. Don't > know if it should be a blocker. If the application will crash, just because net 1.4 is on the classpath, it is a blocker. If an application can run as logn as it does not use the stuff requiring net 2.0, it's unfortunate, but documentation is enough. _ Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Fri, Nov 5, 2010 at 11:30 AM, Ralph Goers wrote: > > Do you really consider this to be a -1? I consider this to be a > documentation issue. User's can pick and choose which providers they want > and simply need to be aware that Net 2.0 requires 1.5. > The providers are auto-registered based on what's on the classpath. So, if they added net 2.0 to their classpath, that provider would be registered. It may not be completely obvious that net 2.0 requires 1.5+. I agree this is probably just a documentation issue. Don't know if it should be a blocker. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 2:49 AM, sebb wrote: > On 5 November 2010 03:05, Ralph Goers wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [X] -1 no, do not release it because... > > The code has a dependency on Commons NET 2.0, which requires Java 1.5+ > However VFS targets Java 1.4+ Do you really consider this to be a -1? I consider this to be a documentation issue. User's can pick and choose which providers they want and simply need to be aware that Net 2.0 requires 1.5. > > > Note: this was found by running the following Maven command: > > mvn package -Pjava-1.4 > > The test is very noisy - not sure it's useful to have the following > lines printed: > > skipping testDeleteOneFiles because TarFileSystem does not have > capability CREATE > > Also, I think LargeTarTestCase should be optional (or ideally be > rewritten to not need so much disk space - not sure that is possible). > > > The source package still contains the DOAP file (not a blocker). > >> >> Ralph >> >> tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >> >> >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-distribution-2.0.pom >> commons-vfs-distribution-2.0-src.tar.gz >> commons-vfs-distribution-2.0-bin.zip >> commons-vfs-distribution-2.0-src.tar.gz.asc >> commons-vfs-distribution-2.0.pom.asc >> commons-vfs-distribution-2.0-src.zip.asc >> commons-vfs-distribution-2.0-src.zip >> commons-vfs-distribution-2.0-bin.tar.gz.asc >> commons-vfs-distribution-2.0-bin.tar.gz >> commons-vfs-distribution-2.0-bin.zip.asc >> commons-vfs-sandbox-2.0-sources.jar.asc >> commons-vfs-sandbox-2.0-sources.jar >> commons-vfs-sandbox-2.0.jar >> commons-vfs-sandbox-2.0.jar.asc >> commons-vfs-sandbox-2.0.pom >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-tests.jar >> commons-vfs-sandbox-2.0-javadoc.jar.asc >> commons-vfs-sandbox-2.0-test-sources.jar.asc >> commons-vfs-sandbox-2.0.pom.asc >> commons-vfs-sandbox-2.0-javadoc.jar >> commons-vfs-sandbox-2.0-test-sources.jar >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0.pom >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.pom.asc >> commons-vfs-project-2.0-site.xml.asc >> commons-vfs-project-2.0.pom >> commons-vfs-project-2.0-site.xml >> commons-vfs-project-2.0.pom.asc > > - > 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: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integratio
Hello. > >> So go ahead with the change, removing the throws from the declaration but > >> keeping the javadoc as suggested previously. > > > > Again, what is it that you try to convey by specifying a single exception in > > the Javadoc? Any unchecked exception can be thrown from a class that > > implement the interface. > > If the user code doesn't care that the evaluation fails, it should catch > > everything and continue. Alternatively, if it cannot continue, it should let > > the exception propagate. In either case, there isn't any useful information > > from a Javadoc "@throws" tag: We already know that unchecked exceptions can > > arise. > > I don't know if it's relevant here, but it's standard practice in lots > of code I've seen to document unchecked exceptions in the @throws > block if your code explicitly throws it. This would be the minimum, but it seems that CM tries to be better in that it aims at also documenting the exceptions thrown from the called code. Of course it is more work on the part of the developer and also more difficult do check for consistency when reading the code (short of following all the calls). > However I would not put this > tag on the interface method declaration, because maybe some > implementation doesn't throw that exception. [...] +1 Best, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1030464 [1/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integratio
> >> So go ahead with the change, removing the throws from the declaration but > >> keeping the javadoc as suggested previously. > > > > Again, what is it that you try to convey by specifying a single exception in > > the Javadoc? Any unchecked exception can be thrown from a class that > > implement the interface. > > If the user code doesn't care that the evaluation fails, it should catch > > everything and continue. Alternatively, if it cannot continue, it should let > > the exception propagate. In either case, there isn't any useful information > > from a Javadoc "@throws" tag: We already know that unchecked exceptions can > > arise. > > Seems to me we should document any Exceptions that our code throws, > along with the reasons for them. > That way, the user can create specific catch clauses. No disagreement about this principle. But the "@throws" Javadoc comment should be placed where we _know_ that the code throws the exception. In "UnivariateRealFunction" it is impossible to know which exception is thrown and which not. > Also, the other RuntimeExceptions are generally unpredictable, whereas > in this case, these Exceptions are only > generated under specific circumstances. Which exceptions? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 4, 2010, at 7:33 PM, Mark Thomas wrote: > On 04/11/2010 14:21, Brian Fox wrote: >>> How about users that want to work with sources on platforms where CRLF >>> endings are a PITA? >> >> Simply tar.gz'ing the files changes the line endings? > > No. Tomcat's build processes are more sophisticated than that. Files in > the -src.zip have CRLF endings, files in the -src.tar.gz have LF endings. Last I checked, Maven did the same thing. Could be that has since been broken. Will check this... Phil > Mark > > > > - > 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: [Math] FunctionEvaluationException in UnivariateRealFunction
Luc, > > [...] > > > > There are at least 2 different issues: > > 1. What is the recommended behaviour of implementations > > 2. What CM will do when it calls "value" and catches an exception > > There is a third issue, and it was a driver for the current architecture. > Some CM algorithms are utilities that are provided by the library that > act on low level user functions and are intended to be called from higher > level user function. They are "sandwiched" between two user levels. Typical > examples are root finding, optimization or ODE integrators. > > In this case, the user knows it's own function and the fact it can fail for > some values. When this case occurs, the function throws some kind of exception > so that the algorithm is interrupted. It does not simply return a NaN as this > would > simply cause a nightmare in the commons math algorithms. The code compiles > only if > the exception was authorized beforehand in the interface (this was the case > with the > former architecture an checked exceptions) or if it is an unchecked exception > (which is > the case now). Of course, the user could have thrown any other unchecked > exception > even in the former architecture. At runtime, the commons-math algorithm does > not > catch the exception, neither the checked one before nor the unchecked one now > (it may > catch it, wrap it in its own exception and throw the wrapped one again, but I > don't > remember any exemple of this behavior in commons-math, only in upper level > libraries > I use). So some exception reached higher level user code, and there the user > can decide > what to do with it. I completely agree with the above. > If the same development team does develop both user levels, declaring > exceptions could > be cumbersome. If different development teams are in charge of the low anf > top level, > it is interesting to have a way to convey development guidelines to them via > javadoc > or declared throws statements. At least with one generic exception like > FunctionEvaluationException, we provide an hint to developers of the low > level function > that it would be wise to stick with this exception type (even if they want to > wrap a > NotPositiveException in it for the sake of better relevance). We also provide > an hint to > developers of the top level algorithm that calls commons-math that the > function they > provide to it and that was provided to them by the other team may throw this > exception > and that commons-math simply let it slip upward. So they are aware they > should at least > understand when this occurs and be able to act properly. >From there I differ because your 3rd case is IMO outside of CM business. If CM let the exceptions propagate (which I'm all for), why bother with it? What do we gain in telling developers what they should do? It is clear that the upper and lower levels teams must communicate (probably through documentation) but whatever they choose as exception doesn't affect CM at all. I maintain that it is misleading to let them believe they should stick to "FunctionEvaluationException"; it's simply not true: this exception or another will just slip upward, as you said. > > > > For (1) I don't think that it is wise to suggest that any function > > should > > throw "FunctionEvaluationException", because this exception doesn't > > convey > > any information. For example, a function that will compute the > > square-root > > should better throw a more specific "NotPositiveException" (a subclass > > of > > "IllegalArgumentException") when passed a negative argument. > > Yes, a more focused exception would be better. It is also possible to > wrap a focused NotPositiveException into a general FunctionEvaluationException > and get the best of both worlds. I don't think that it's the best of both, because the wrapping doesn't serve any purpose. > We cannot enforce it at java level. Then, since the users must resort to policy/documentation, it isn't any easier to stick to the "FunctionEvaluationException" policy than to any other policy. > > > > > If some part of CM wants to catch a failure (e.g. because the > > computation > > can meaningfully continue, or just to provide a localized message), it > > is > > certainly not safe to catch only "FunctionEvaluationException" since > > indeed > > we cannot enforce that it will be the only exception type to arise. > > Hence, for (2), we will catch *any* "RuntimeException" (and continue, > > or > > throw a "FunctionEvaluationException"). > > Yes, most of the time I think commons-math will not catch these exceptions > at all. > > > It is thus useless and misleading to recommend something that we don't > > care > > about. > > Despite I agree with the premisses, I don't agree with this conclusion. We > do care about these exception and we could document them. Simply we cannot > handle them by ourselves and we let them slip upward to the user code calling > our code. As you've just said: We c
[continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=1421&projectId=97 Build statistics: State: Failed Previous State: Failed Started at: Fri 5 Nov 2010 14:26:26 + Finished at: Fri 5 Nov 2010 14:30:40 + Total time: 4m 13s Build Trigger: Schedule Build Number: 61 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-24-server" arch: "amd64" Family: "unix" SCM Changes: Changed: erans @ Fri 5 Nov 2010 14:13:41 + Comment: MATH-432 New class "Pair" as a replacement for the standard class "AbstractMap.SimpleEntry" (available in Java 1.6). Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/Pair.java ( 1031574 ) /commons/proper/math/trunk/src/site/xdoc/changes.xml ( 1031574 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math/util/PairTest.java ( 1031574 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install 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: 0 Failures: 0 Errors: 0 Total time: 0.0 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons BeanUtils - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=1417&projectId=65 Build statistics: State: Failed Previous State: Failed Started at: Fri 5 Nov 2010 13:38:23 + Finished at: Fri 5 Nov 2010 13:42:43 + Total time: 4m 20s Build Trigger: Schedule Build Number: 3 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-24-server" arch: "amd64" Family: "unix" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install 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: 1180 Failures: 0 Errors: 1 Success Rate: 99 Total time: 67.147995 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Collections] Generic Fork
- "Henri Yandell" a écrit : > Though depends on what you're submitting. JIRA issues, no worries. > Just hit the checkbox each time you add a patch. > > If you become a committer, or if you're submitting something large, > then we will ask you to sign an ICLA. > > When signing an ICLA, your company may want to sign a CCLA - it's > entirely up to your employer and not required by us. It may protect him in case his employer later consider the code did not initially belong to him and he did not have the right to contribute it to an Apache project. Luc > > Hen > > On Thu, Nov 4, 2010 at 5:54 PM, Davanum Srinivas > wrote: > > Joerg, > > > > You need to sign the ICLA and your company should file a CCLA if > > appropriate. both are listed here: > > http://www.apache.org/licenses/ > > > > thanks, > > dims > > > > On Thu, Nov 4, 2010 at 8:52 PM, Grant Overby > wrote: > >> I was unaware that there is official work being done for generics. > This is > >> excellent news. > >> > >> I've taken my first look at trunk & jira. I have a potential > solution for > >> https://issues.apache.org/jira/browse/COLLECTIONS-237 . See my > comment on > >> the issue. > >> > >> Another question: > >> I presume that I would need an officer of my company (and myself) > to sign: > >> http://www.apache.org/licenses/icla.txt . Is this correct? Is this > all that > >> is needed to protect the ASF? > >> > >> > >> -- > >> Grant Overby > >> Senior Developer > >> FloorSoft, Inc. > >> > >> Often people, especially computer engineers, focus on the machines. > They > >> think, "By doing this, the machine will run faster. By doing this, > the > >> machine will run more effectively. By doing this, the machine will > something > >> something something." They are focusing on machines. But in fact we > need to > >> focus on humans, on how humans care about doing programming or > operating the > >> application of the machines. We are the masters. They are the > slaves. -- > >> Yukihiro Matsumoto > >> > >> > >> > >> > >> On Thu, Nov 4, 2010 at 5:20 PM, Jörg Schaible > wrote: > >> > >>> velopment is as usual by creating patches in > >> > > > > > > > > -- > > Davanum Srinivas :: http://davanum.wordpress.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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] FunctionEvaluationException in UnivariateRealFunction (Was: Re: svn commit: r1030464 [1/3] - ...)
Hi Gilles, and sorry for mistyping your name in my previous message, - "Gilles Sadowski" a écrit : > Hi. > > > > [...] > > > > > > > > What about new code? With the current signature and > documentation > > > > there is no information on possible exception conditions. The > fact > > > > the method will throw an exception on failure needs to be > > > expressed. > > > > > > > > [...] > > > > > > The fact is: You don't know whether an exception will be raised > on > > > failure. > > > It depends on the implementation: A user might decide that failure > is > > > dealt with by returning "NaN" (or Infinity). > > > Another user might decide to throw a > "MathIllegalArgumentException" or > > > a > > > subclass thereof or something completely different... :-) > > > IMHO, the "FunctionEvaluationException" is fairly useless. Its > only > > > use I > > > can see is to wrap "alien" (user-defined) exceptions: Any methods > in > > > > When this exception was unchecked, it was the primary use of it : > wrapping > > exceptions unknown to [math]. Of course, we cannot enforce users to > use it > > and even when it was checked users could decide to throw any other > unchecked > > exceptions or return NaN. Documenting it is simply a gentle way to > tell our > > users this exception is the recommended way to signal errors. > > > There are at least 2 different issues: > 1. What is the recommended behaviour of implementations > 2. What CM will do when it calls "value" and catches an exception There is a third issue, and it was a driver for the current architecture. Some CM algorithms are utilities that are provided by the library that act on low level user functions and are intended to be called from higher level user function. They are "sandwiched" between two user levels. Typical examples are root finding, optimization or ODE integrators. In this case, the user knows it's own function and the fact it can fail for some values. When this case occurs, the function throws some kind of exception so that the algorithm is interrupted. It does not simply return a NaN as this would simply cause a nightmare in the commons math algorithms. The code compiles only if the exception was authorized beforehand in the interface (this was the case with the former architecture an checked exceptions) or if it is an unchecked exception (which is the case now). Of course, the user could have thrown any other unchecked exception even in the former architecture. At runtime, the commons-math algorithm does not catch the exception, neither the checked one before nor the unchecked one now (it may catch it, wrap it in its own exception and throw the wrapped one again, but I don't remember any exemple of this behavior in commons-math, only in upper level libraries I use). So some exception reached higher level user code, and there the user can decide what to do with it. If the same development team does develop both user levels, declaring exceptions could be cumbersome. If different development teams are in charge of the low anf top level, it is interesting to have a way to convey development guidelines to them via javadoc or declared throws statements. At least with one generic exception like FunctionEvaluationException, we provide an hint to developers of the low level function that it would be wise to stick with this exception type (even if they want to wrap a NotPositiveException in it for the sake of better relevance). We also provide an hint to developers of the top level algorithm that calls commons-math that the function they provide to it and that was provided to them by the other team may throw this exception and that commons-math simply let it slip upward. So they are aware they should at least understand when this occurs and be able to act properly. > > For (1) I don't think that it is wise to suggest that any function > should > throw "FunctionEvaluationException", because this exception doesn't > convey > any information. For example, a function that will compute the > square-root > should better throw a more specific "NotPositiveException" (a subclass > of > "IllegalArgumentException") when passed a negative argument. Yes, a more focused exception would be better. It is also possible to wrap a focused NotPositiveException into a general FunctionEvaluationException and get the best of both worlds. We cannot enforce it at java level. > > If some part of CM wants to catch a failure (e.g. because the > computation > can meaningfully continue, or just to provide a localized message), it > is > certainly not safe to catch only "FunctionEvaluationException" since > indeed > we cannot enforce that it will be the only exception type to arise. > Hence, for (2), we will catch *any* "RuntimeException" (and continue, > or > throw a "FunctionEvaluationException"). Yes, most of the time I think commons-math will not catch these exceptions at all. > It is thus useless and misleading to recommend something that we d
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 2:49 AM, sebb wrote: > On 5 November 2010 03:05, Ralph Goers wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [X] -1 no, do not release it because... > > The code has a dependency on Commons NET 2.0, which requires Java 1.5+ > However VFS targets Java 1.4+ So any of the providers that require commons net require 1.5. I guess the documentation will have to be updated to call that out. Is that a blocker? > > > Note: this was found by running the following Maven command: > > mvn package -Pjava-1.4 > > The test is very noisy - not sure it's useful to have the following > lines printed: > > skipping testDeleteOneFiles because TarFileSystem does not have > capability CREATE > > Also, I think LargeTarTestCase should be optional (or ideally be > rewritten to not need so much disk space - not sure that is possible). > > > The source package still contains the DOAP file (not a blocker). > >> >> Ralph >> >> tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >> >> >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-distribution-2.0.pom >> commons-vfs-distribution-2.0-src.tar.gz >> commons-vfs-distribution-2.0-bin.zip >> commons-vfs-distribution-2.0-src.tar.gz.asc >> commons-vfs-distribution-2.0.pom.asc >> commons-vfs-distribution-2.0-src.zip.asc >> commons-vfs-distribution-2.0-src.zip >> commons-vfs-distribution-2.0-bin.tar.gz.asc >> commons-vfs-distribution-2.0-bin.tar.gz >> commons-vfs-distribution-2.0-bin.zip.asc >> commons-vfs-sandbox-2.0-sources.jar.asc >> commons-vfs-sandbox-2.0-sources.jar >> commons-vfs-sandbox-2.0.jar >> commons-vfs-sandbox-2.0.jar.asc >> commons-vfs-sandbox-2.0.pom >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-tests.jar >> commons-vfs-sandbox-2.0-javadoc.jar.asc >> commons-vfs-sandbox-2.0-test-sources.jar.asc >> commons-vfs-sandbox-2.0.pom.asc >> commons-vfs-sandbox-2.0-javadoc.jar >> commons-vfs-sandbox-2.0-test-sources.jar >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0.pom >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.pom.asc >> commons-vfs-project-2.0-site.xml.asc >> commons-vfs-project-2.0.pom >> commons-vfs-project-2.0-site.xml >> commons-vfs-project-2.0.pom.asc > > - > 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
[Math] FunctionEvaluationException in UnivariateRealFunction (Was: Re: svn commit: r1030464 [1/3] - ...)
Hi. > > [...] > > > > > > What about new code? With the current signature and documentation > > > there is no information on possible exception conditions. The fact > > > the method will throw an exception on failure needs to be > > expressed. > > > > > > [...] > > > > The fact is: You don't know whether an exception will be raised on > > failure. > > It depends on the implementation: A user might decide that failure is > > dealt with by returning "NaN" (or Infinity). > > Another user might decide to throw a "MathIllegalArgumentException" or > > a > > subclass thereof or something completely different... :-) > > IMHO, the "FunctionEvaluationException" is fairly useless. Its only > > use I > > can see is to wrap "alien" (user-defined) exceptions: Any methods in > > When this exception was unchecked, it was the primary use of it : wrapping > exceptions unknown to [math]. Of course, we cannot enforce users to use it > and even when it was checked users could decide to throw any other unchecked > exceptions or return NaN. Documenting it is simply a gentle way to tell our > users this exception is the recommended way to signal errors. There are at least 2 different issues: 1. What is the recommended behaviour of implementations 2. What CM will do when it calls "value" and catches an exception For (1) I don't think that it is wise to suggest that any function should throw "FunctionEvaluationException", because this exception doesn't convey any information. For example, a function that will compute the square-root should better throw a more specific "NotPositiveException" (a subclass of "IllegalArgumentException") when passed a negative argument. If some part of CM wants to catch a failure (e.g. because the computation can meaningfully continue, or just to provide a localized message), it is certainly not safe to catch only "FunctionEvaluationException" since indeed we cannot enforce that it will be the only exception type to arise. Hence, for (2), we will catch *any* "RuntimeException" (and continue, or throw a "FunctionEvaluationException"). It is thus useless and misleading to recommend something that we don't care about. Thus, neither (1) nor (2) is reason for letting appear the word "FunctionEvaluationException" within the interface file. To summarize, a "FunctionEvaluationException" class only makes sense, IMHO, for the localization (of exception messages) requirement: Catch every exception and wrap it in a "FunctionEvaluationException". [If you agree with this use-case, I'll modify the new "FunctionEvaluationException" so that it takes the cause as its argument.] Please let me know whether you have use cases that would contradict the above. > > [...] Best, ;-) Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 3:03 AM, sebb wrote: > On 5 November 2010 09:49, sebb wrote: >> On 5 November 2010 03:05, Ralph Goers wrote: >>> This is a vote to release Apache Commons VFS 2.0. >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [X] -1 no, do not release it because... >> >> The code has a dependency on Commons NET 2.0, which requires Java 1.5+ >> However VFS targets Java 1.4+ >> >> >> Note: this was found by running the following Maven command: >> >> mvn package -Pjava-1.4 >> >> The test is very noisy - not sure it's useful to have the following >> lines printed: >> >> skipping testDeleteOneFiles because TarFileSystem does not have >> capability CREATE >> >> Also, I think LargeTarTestCase should be optional (or ideally be >> rewritten to not need so much disk space - not sure that is possible). > > Given that the tgz version of the file is 'only' 3MB, maybe that could > just be included as a test resource? > That would save time creating it, and might avoid the need to depend > on Compress. I actually thought about doing that before I went to bed last night. > >> >> The source package still contains the DOAP file (not a blocker). >> >>> >>> Ralph >>> >>> tag: >>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >>> >>> site: http://people.apache.org/~rgoers/commons-vfs/index.html >>> >>> The following artifacts have been staged to the Apache Nexus Staging >>> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >>> >>> >>> commons-vfs-examples-2.0.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar.asc >>> commons-vfs-examples-2.0.pom.asc >>> commons-vfs-examples-2.0.jar >>> commons-vfs-examples-2.0.pom >>> commons-vfs-examples-2.0-sources.jar >>> commons-vfs-examples-2.0-sources.jar.asc >>> commons-vfs-examples-2.0-javadoc.jar >>> commons-vfs-distribution-2.0.pom >>> commons-vfs-distribution-2.0-src.tar.gz >>> commons-vfs-distribution-2.0-bin.zip >>> commons-vfs-distribution-2.0-src.tar.gz.asc >>> commons-vfs-distribution-2.0.pom.asc >>> commons-vfs-distribution-2.0-src.zip.asc >>> commons-vfs-distribution-2.0-src.zip >>> commons-vfs-distribution-2.0-bin.tar.gz.asc >>> commons-vfs-distribution-2.0-bin.tar.gz >>> commons-vfs-distribution-2.0-bin.zip.asc >>> commons-vfs-sandbox-2.0-sources.jar.asc >>> commons-vfs-sandbox-2.0-sources.jar >>> commons-vfs-sandbox-2.0.jar >>> commons-vfs-sandbox-2.0.jar.asc >>> commons-vfs-sandbox-2.0.pom >>> commons-vfs-sandbox-2.0-tests.jar.asc >>> commons-vfs-sandbox-2.0-tests.jar >>> commons-vfs-sandbox-2.0-javadoc.jar.asc >>> commons-vfs-sandbox-2.0-test-sources.jar.asc >>> commons-vfs-sandbox-2.0.pom.asc >>> commons-vfs-sandbox-2.0-javadoc.jar >>> commons-vfs-sandbox-2.0-test-sources.jar >>> commons-vfs-2.0-test-sources.jar >>> commons-vfs-2.0-sources.jar.asc >>> commons-vfs-2.0-tests.jar.asc >>> commons-vfs-2.0-tests.jar >>> commons-vfs-2.0-javadoc.jar >>> commons-vfs-2.0-test-sources.jar.asc >>> commons-vfs-2.0.pom >>> commons-vfs-2.0-javadoc.jar.asc >>> commons-vfs-2.0.jar >>> commons-vfs-2.0.jar.asc >>> commons-vfs-2.0-sources.jar >>> commons-vfs-2.0.pom.asc >>> commons-vfs-project-2.0-site.xml.asc >>> commons-vfs-project-2.0.pom >>> commons-vfs-project-2.0-site.xml >>> commons-vfs-project-2.0.pom.asc >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On Nov 5, 2010, at 2:00 AM, sebb wrote: > On 5 November 2010 03:05, Ralph Goers wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [ ] -1 no, do not release it because... >> >> Ralph >> >> tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ > > Which revision of the tag is involved here? The tag has been recreated > several times. r1031408 > >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) > > Please in future include the link to the code, so we don't all have to > search for it: > > https://repository.apache.org/content/repositories/orgapachecommons-036/org/apache/commons/ > (at least I assume that is the correct code?) Sorry - in the line above org.apache.commons-036 was supposed to be a hyperlink. > >> >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-distribution-2.0.pom >> commons-vfs-distribution-2.0-src.tar.gz >> commons-vfs-distribution-2.0-bin.zip >> commons-vfs-distribution-2.0-src.tar.gz.asc >> commons-vfs-distribution-2.0.pom.asc >> commons-vfs-distribution-2.0-src.zip.asc >> commons-vfs-distribution-2.0-src.zip >> commons-vfs-distribution-2.0-bin.tar.gz.asc >> commons-vfs-distribution-2.0-bin.tar.gz >> commons-vfs-distribution-2.0-bin.zip.asc >> commons-vfs-sandbox-2.0-sources.jar.asc >> commons-vfs-sandbox-2.0-sources.jar >> commons-vfs-sandbox-2.0.jar >> commons-vfs-sandbox-2.0.jar.asc >> commons-vfs-sandbox-2.0.pom >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-tests.jar >> commons-vfs-sandbox-2.0-javadoc.jar.asc >> commons-vfs-sandbox-2.0-test-sources.jar.asc >> commons-vfs-sandbox-2.0.pom.asc >> commons-vfs-sandbox-2.0-javadoc.jar >> commons-vfs-sandbox-2.0-test-sources.jar >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0.pom >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.pom.asc >> commons-vfs-project-2.0-site.xml.asc >> commons-vfs-project-2.0.pom >> commons-vfs-project-2.0-site.xml >> commons-vfs-project-2.0.pom.asc > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: svn commit: r1030464 [2/3] - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/ main/java/org/apache/commons/math/analysis/ main/java/org/apache/commons/math/analysis/integratio
On 4 November 2010 22:18, Gilles Sadowski wrote:
>> > Modified:
>> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java
>> > URL:
>> > http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java?rev=1030464&r1=1030463&r2=1030464&view=diff
>> > ==
>> > ---
>> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java
>> > (original)
>> > +++
>> > commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/MathUtils.java
>> > Wed Nov 3 13:46:04 2010
>> ...
>> > @@ -1929,58 +1906,139 @@ public final class MathUtils {
>> ...
>>
>> > + yValues[j] = y[i];
>> > + }
>> > + list.add(new AbstractMap.SimpleEntry(x[i],
>> > yValues));
>>
>> Requires Java 1.6+
>
> Then I propose to create a class Pair in the "util" package. Is that
> OK? If so, I'll fix this problem tomorrow.
Seems OK to me.
>
> Regards,
> Gilles
>
> -
> 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: [scxml-eclipse]Hi
I do not think we can help you to debug your source code, but you can give us some detail questions in your project, may be we can help you. In fact, as Rahul told you, you can visit our Visual SCXML editor web site first, maybe you can use our source code, or even improve it 2010/11/5 Bilel Messaoud > Hi im student and i have a project to create scxml editor so i used emf and > gef now i tried to use Translators but really i was blocked can i show u my > sources and can u help me im blocked and it really stress me > thx > -- Best Regards Gui Xun Long (桂训龙)
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 09:49, sebb wrote: > On 5 November 2010 03:05, Ralph Goers wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [X] -1 no, do not release it because... > > The code has a dependency on Commons NET 2.0, which requires Java 1.5+ > However VFS targets Java 1.4+ > > > Note: this was found by running the following Maven command: > > mvn package -Pjava-1.4 > > The test is very noisy - not sure it's useful to have the following > lines printed: > > skipping testDeleteOneFiles because TarFileSystem does not have > capability CREATE > > Also, I think LargeTarTestCase should be optional (or ideally be > rewritten to not need so much disk space - not sure that is possible). Given that the tgz version of the file is 'only' 3MB, maybe that could just be included as a test resource? That would save time creating it, and might avoid the need to depend on Compress. > > The source package still contains the DOAP file (not a blocker). > >> >> Ralph >> >> tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) >> >> >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-distribution-2.0.pom >> commons-vfs-distribution-2.0-src.tar.gz >> commons-vfs-distribution-2.0-bin.zip >> commons-vfs-distribution-2.0-src.tar.gz.asc >> commons-vfs-distribution-2.0.pom.asc >> commons-vfs-distribution-2.0-src.zip.asc >> commons-vfs-distribution-2.0-src.zip >> commons-vfs-distribution-2.0-bin.tar.gz.asc >> commons-vfs-distribution-2.0-bin.tar.gz >> commons-vfs-distribution-2.0-bin.zip.asc >> commons-vfs-sandbox-2.0-sources.jar.asc >> commons-vfs-sandbox-2.0-sources.jar >> commons-vfs-sandbox-2.0.jar >> commons-vfs-sandbox-2.0.jar.asc >> commons-vfs-sandbox-2.0.pom >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-tests.jar >> commons-vfs-sandbox-2.0-javadoc.jar.asc >> commons-vfs-sandbox-2.0-test-sources.jar.asc >> commons-vfs-sandbox-2.0.pom.asc >> commons-vfs-sandbox-2.0-javadoc.jar >> commons-vfs-sandbox-2.0-test-sources.jar >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0.pom >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.pom.asc >> commons-vfs-project-2.0-site.xml.asc >> commons-vfs-project-2.0.pom >> commons-vfs-project-2.0-site.xml >> commons-vfs-project-2.0.pom.asc > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 03:05, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [X] -1 no, do not release it because... The code has a dependency on Commons NET 2.0, which requires Java 1.5+ However VFS targets Java 1.4+ Note: this was found by running the following Maven command: mvn package -Pjava-1.4 The test is very noisy - not sure it's useful to have the following lines printed: skipping testDeleteOneFiles because TarFileSystem does not have capability CREATE Also, I think LargeTarTestCase should be optional (or ideally be rewritten to not need so much disk space - not sure that is possible). The source package still contains the DOAP file (not a blocker). > > Ralph > > tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) > > > commons-vfs-examples-2.0.jar.asc > commons-vfs-examples-2.0-javadoc.jar.asc > commons-vfs-examples-2.0.pom.asc > commons-vfs-examples-2.0.jar > commons-vfs-examples-2.0.pom > commons-vfs-examples-2.0-sources.jar > commons-vfs-examples-2.0-sources.jar.asc > commons-vfs-examples-2.0-javadoc.jar > commons-vfs-distribution-2.0.pom > commons-vfs-distribution-2.0-src.tar.gz > commons-vfs-distribution-2.0-bin.zip > commons-vfs-distribution-2.0-src.tar.gz.asc > commons-vfs-distribution-2.0.pom.asc > commons-vfs-distribution-2.0-src.zip.asc > commons-vfs-distribution-2.0-src.zip > commons-vfs-distribution-2.0-bin.tar.gz.asc > commons-vfs-distribution-2.0-bin.tar.gz > commons-vfs-distribution-2.0-bin.zip.asc > commons-vfs-sandbox-2.0-sources.jar.asc > commons-vfs-sandbox-2.0-sources.jar > commons-vfs-sandbox-2.0.jar > commons-vfs-sandbox-2.0.jar.asc > commons-vfs-sandbox-2.0.pom > commons-vfs-sandbox-2.0-tests.jar.asc > commons-vfs-sandbox-2.0-tests.jar > commons-vfs-sandbox-2.0-javadoc.jar.asc > commons-vfs-sandbox-2.0-test-sources.jar.asc > commons-vfs-sandbox-2.0.pom.asc > commons-vfs-sandbox-2.0-javadoc.jar > commons-vfs-sandbox-2.0-test-sources.jar > commons-vfs-2.0-test-sources.jar > commons-vfs-2.0-sources.jar.asc > commons-vfs-2.0-tests.jar.asc > commons-vfs-2.0-tests.jar > commons-vfs-2.0-javadoc.jar > commons-vfs-2.0-test-sources.jar.asc > commons-vfs-2.0.pom > commons-vfs-2.0-javadoc.jar.asc > commons-vfs-2.0.jar > commons-vfs-2.0.jar.asc > commons-vfs-2.0-sources.jar > commons-vfs-2.0.pom.asc > commons-vfs-project-2.0-site.xml.asc > commons-vfs-project-2.0.pom > commons-vfs-project-2.0-site.xml > commons-vfs-project-2.0.pom.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
On 5 November 2010 03:05, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... > > Ralph > > tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ Which revision of the tag is involved here? The tag has been recreated several times. > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-036 (u:rgoers, a:38.110.32.2) Please in future include the link to the code, so we don't all have to search for it: https://repository.apache.org/content/repositories/orgapachecommons-036/org/apache/commons/ (at least I assume that is the correct code?) > > commons-vfs-examples-2.0.jar.asc > commons-vfs-examples-2.0-javadoc.jar.asc > commons-vfs-examples-2.0.pom.asc > commons-vfs-examples-2.0.jar > commons-vfs-examples-2.0.pom > commons-vfs-examples-2.0-sources.jar > commons-vfs-examples-2.0-sources.jar.asc > commons-vfs-examples-2.0-javadoc.jar > commons-vfs-distribution-2.0.pom > commons-vfs-distribution-2.0-src.tar.gz > commons-vfs-distribution-2.0-bin.zip > commons-vfs-distribution-2.0-src.tar.gz.asc > commons-vfs-distribution-2.0.pom.asc > commons-vfs-distribution-2.0-src.zip.asc > commons-vfs-distribution-2.0-src.zip > commons-vfs-distribution-2.0-bin.tar.gz.asc > commons-vfs-distribution-2.0-bin.tar.gz > commons-vfs-distribution-2.0-bin.zip.asc > commons-vfs-sandbox-2.0-sources.jar.asc > commons-vfs-sandbox-2.0-sources.jar > commons-vfs-sandbox-2.0.jar > commons-vfs-sandbox-2.0.jar.asc > commons-vfs-sandbox-2.0.pom > commons-vfs-sandbox-2.0-tests.jar.asc > commons-vfs-sandbox-2.0-tests.jar > commons-vfs-sandbox-2.0-javadoc.jar.asc > commons-vfs-sandbox-2.0-test-sources.jar.asc > commons-vfs-sandbox-2.0.pom.asc > commons-vfs-sandbox-2.0-javadoc.jar > commons-vfs-sandbox-2.0-test-sources.jar > commons-vfs-2.0-test-sources.jar > commons-vfs-2.0-sources.jar.asc > commons-vfs-2.0-tests.jar.asc > commons-vfs-2.0-tests.jar > commons-vfs-2.0-javadoc.jar > commons-vfs-2.0-test-sources.jar.asc > commons-vfs-2.0.pom > commons-vfs-2.0-javadoc.jar.asc > commons-vfs-2.0.jar > commons-vfs-2.0.jar.asc > commons-vfs-2.0-sources.jar > commons-vfs-2.0.pom.asc > commons-vfs-project-2.0-site.xml.asc > commons-vfs-project-2.0.pom > commons-vfs-project-2.0-site.xml > commons-vfs-project-2.0.pom.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
