[bcel] Backwards Incompatible Change to Visitor
Hi, with svn revision 1158060 the bcel.generic.Visitor interface has become package private, breaking the Gump builds of Xalan XSLTC, commons-javaflow and likely other downstream code. Has this change been intentional? Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-email (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-email has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 174 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-email : Commons Email Package Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-email/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-email-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/email/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-email/gump_work/build_apache-commons_commons-email.html Work Name: build_apache-commons_commons-email (Type: Build) Work ended in a state of : Failed Elapsed: 38 secs Command Line: /opt/maven2/bin/mvn --batch-mode -Dmaven.jar.mail=/srv/gump/packages/javamail-1.4/mail.jar --settings /srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/email] M2_HOME: /opt/maven2 - log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.439 sec Running org.apache.commons.mail.EmailLiveTest Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.241 sec Running org.apache.commons.mail.SendWithAttachmentsTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec Running org.apache.commons.mail.DataSourceResolverTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.mail.util.MimeMessageParserTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.121 sec Running org.apache.commons.mail.EmailTest Tests run: 40, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.227 sec Running org.apache.commons.mail.EmailAttachmentTest Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.259 sec Running org.apache.commons.mail.ImageHtmlEmailTest Tests run: 18, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.176 sec FAILURE! Running org.apache.commons.mail.DefaultAuthenticatorTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.mail.util.URLFactoryTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.mail.SimpleEmailTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.mail.MultiPartEmailTest Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.055 sec Running org.apache.commons.mail.InvalidInternetAddressTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.mail.InvalidAddressTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Results : Failed tests: testSendHtml(org.apache.commons.mail.ImageHtmlEmailTest) Tests run: 108, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/email/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 37 seconds [INFO] Finished at: Wed Aug 17 07:50:26 UTC 2011 [INFO] Final Memory: 32M/78M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-email/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-email/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06000617082011, vmgump.apache.org:vmgump:06000617082011 Gump E-mail Identifier
Re: [bcel] Backwards Incompatible Change to Visitor
On Wed, Aug 17, 2011 at 8:06 AM, Stefan Bodewig bode...@apache.org wrote: Hi, with svn revision 1158060 the bcel.generic.Visitor interface has become package private, breaking the Gump builds of Xalan XSLTC, commons-javaflow and likely other downstream code. Gump is so cool :) cheers, Torsten - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] iterator and sparseIterator in RealVector hierarchy
Ted, please just take your code and move IteratorEntry sparseIterator(); from RealVector to SparseRealvector. Look then at the compiler errors, that are in most cases misuses of sparseIterator(). By the way most(all?) functions in CM return an array (dense) impementation as return type. You mention the method isSparse in your posts - there is currently no such method, if you want to detect, if you have a sparse implementation you will have to check for SparseRealvector. So there is no big deal in a following cast to SparseRealVector to access sparseIterator(). As I am no math guru, I cant follow your example, some real code probaply will do the trick. Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. This matrix and siblings is very important in compressed sensing and stochastic projection algorithms. On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/16/11 4:46 AM, Gilles Sadowski wrote: Hi. I understood what he was suggesting. I still disagree. Dynamic dispatch and non-lattice typing structure is still required to make this all work. Java doesn't really do that. Pretending that what Java does is sufficient is hammer-looking-for-a-nail, not solving the problems at hand. Maybe that *I* don't understand what you are hinting at. Sorry for being dense. [Although that seems appropriate in this discussion :-).] Polymorphism provides dynamic dispatch, overloading does not; that's why my proposition is that when you manipulate unknown types, those should come as this, not as the argument of the method. What's wrong with that? As for hammer-looking-for-a-nail, I also don't see what you mean: What is the problem? I guess that there are lots of applications who never need to know about sparse vectors/matrices. In those cases, the added complexity is not a feature. The issue reported contends that the current design in CM can cause problems for dense implementations. I'm not even sure that the current design is usable for the type of applications that make heavy use of sparseness. Those are problems, IMHO. I have been out of pocket the last couple of days and may not have time to dig into this until late tonight, but I agree with Gilles that we need to get the conversation here more concrete. I know we discussed this before and Ted and others had good examples justifying the current setup. Can we revisit these, please? What would be great would be some examples both from the perspective of the [math] developer looking to add a new or specialized class and [math] users writing code that leverages the setup. Phil Gilles On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski gsterijev...@gmail.comwrote: Forgive me for pushing my nose under the tent... I couldn't resist. I think Gilles is saying that each specialization of the matrix/vector objects would need to support pre (and post) multiplication with a dense. So the type issue would not be problematic. On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning ted.dunn...@gmail.com wrote: No. You can't. This is because the type is lost as you enter the generic library. On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: They know that their own object is dense, but they don't know what kind of input they were given. They should still run fast if the input is sparse. Couldn't we still rely on polymorphism by implementing preTimes: unknown.preTimes(dense) - 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] iterator and sparseIterator in RealVector hierarchy
Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for sparseIterator ? Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. This matrix and siblings is very important in compressed sensing and stochastic projection algorithms. On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/16/11 4:46 AM, Gilles Sadowski wrote: Hi. I understood what he was suggesting. I still disagree. Dynamic dispatch and non-lattice typing structure is still required to make this all work. Java doesn't really do that. Pretending that what Java does is sufficient is hammer-looking-for-a-nail, not solving the problems at hand. Maybe that *I* don't understand what you are hinting at. Sorry for being dense. [Although that seems appropriate in this discussion :-).] Polymorphism provides dynamic dispatch, overloading does not; that's why my proposition is that when you manipulate unknown types, those should come as this, not as the argument of the method. What's wrong with that? As for hammer-looking-for-a-nail, I also don't see what you mean: What is the problem? I guess that there are lots of applications who never need to know about sparse vectors/matrices. In those cases, the added complexity is not a feature. The issue reported contends that the current design in CM can cause problems for dense implementations. I'm not even sure that the current design is usable for the type of applications that make heavy use of sparseness. Those are problems, IMHO. I have been out of pocket the last couple of days and may not have time to dig into this until late tonight, but I agree with Gilles that we need to get the conversation here more concrete. I know we discussed this before and Ted and others had good examples justifying the current setup. Can we revisit these, please? What would be great would be some examples both from the perspective of the [math] developer looking to add a new or specialized class and [math] users writing code that leverages the setup. Phil Gilles On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski gsterijev...@gmail.comwrote: Forgive me for pushing my nose under the tent... I couldn't resist. I think Gilles is saying that each specialization of the matrix/vector objects would need to support pre (and post) multiplication with a dense. So the type issue would not be problematic. On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning ted.dunn...@gmail.com wrote: No. You can't. This is because the type is lost as you enter the generic library. On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: They know that their own object is dense, but they don't know what kind of input they were given. They should still run fast if the input is sparse. Couldn't we still rely on polymorphism by implementing preTimes: unknown.preTimes(dense) - 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
[GUMP@vmgump]: Project commons-javaflow (in module commons-sandbox) 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-javaflow has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-javaflow : Commons Javaflow Full details are available at: http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/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-javaflow-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/commons-sandbox/javaflow/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-sandbox/javaflow/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/commons-sandbox/javaflow/target/surefire-reports -WARNING- No directory [/srv/gump/public/workspace/commons-sandbox/javaflow/target/surefire-reports] -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-sandbox/commons-javaflow/gump_work/build_commons-sandbox_commons-javaflow.html Work Name: build_commons-sandbox_commons-javaflow (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/commons-sandbox/javaflow/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/commons-sandbox/javaflow] M2_HOME: /opt/maven2 - [INFO] Scanning for projects... [INFO] [INFO] Building Commons Javaflow (Sandbox) [INFO]task-segment: [package] [INFO] Downloading: http://localhost:8192/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.pom Downloading: http://localhost:8192/maven2/asm/asm-util/3.2/asm-util-3.2.pom Downloading: http://localhost:8192/maven2/asm/asm-analysis/3.2/asm-analysis-3.2.jar 17K downloaded (asm-analysis-3.2.jar) Downloading: http://localhost:8192/maven2/asm/asm-util/3.2/asm-util-3.2.jar 34K downloaded (asm-util-3.2.jar) [INFO] [antrun:run {execution: javadoc.resources}] [INFO] Executing tasks [copy] Copying 2 files to /srv/gump/public/workspace/commons-sandbox/javaflow/target/apidocs/META-INF [INFO] Executed tasks [INFO] Setting property: classpath.resource.loader.class = 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'. [INFO] Setting property: velocimacro.messages.on = 'false'. [INFO] Setting property: resource.loader = 'classpath'. [INFO] Setting property: resource.manager.logwhenfound = 'false'. [INFO] [remote-resources:process {execution: default}] [INFO] [resources:resources {execution: default-resources}] [INFO] Using 'iso-8859-1' encoding to copy filtered resources. [INFO] Copying 2 resources to META-INF [INFO] [compiler:compile {execution: default-compile}] [INFO] Compiling 35 source files to /srv/gump/public/workspace/commons-sandbox/javaflow/target/classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /srv/gump/public/workspace/commons-sandbox/javaflow/src/main/java/org/apache/commons/javaflow/bytecode/transformation/bcel/analyser/ExecutionVisitor.java:[57,62] org.apache.bcel.generic.Visitor is not public in org.apache.bcel.generic; cannot be accessed from outside package [INFO] 1error [INFO] - [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /srv/gump/public/workspace/commons-sandbox/javaflow/src/main/java/org/apache/commons/javaflow/bytecode/transformation/bcel/analyser/ExecutionVisitor.java:[57,62] org.apache.bcel.generic.Visitor is not public in org.apache.bcel.generic; cannot be accessed from outside package [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Wed Aug 17 10:56:30 UTC 2011 [INFO] Final Memory: 22M/58M [INFO]
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 42 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 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.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.025 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.166 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 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.016 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: 10 seconds [INFO] Finished at: Wed Aug 17 10:57:56 UTC 2011 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
Re: [Math] iterator and sparseIterator in RealVector hierarchy
On Tue, Aug 16, 2011 at 02:09:03PM -0700, Ted Dunning wrote: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. Do you mean that the matrix is stateless (each call to get generates a new value)? If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. As far as I understand, the sparseness test is an indicator that there is an optimized way to iterate over the entries (faster than a loop over all the indices) or that not all entries are explicitly stored. Is that correct? If so, this is tied to the layout of the matrix, i.e. the type (which can change depending on an input value, such as p above). However, once it is created, its type/implementation is either dense or sparse. [...] I'm wondering whether this leads again to the issue of CM being a framework for everyone to build on, or if its data structures are mostly intended for internal use, so that the algorithms it provides are most efficient. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1158504 - /commons/trunks-proper/
On 17 August 2011 05:38, Stefan Bodewig bode...@apache.org wrote: On 2011-08-17, bay...@apache.org wrote: Propchange: commons/trunks-proper/ -- --- svn:externals (original) +++ svn:externals Wed Aug 17 04:25:55 2011 @@ -2,6 +2,7 @@ attributes https://svn.apache.org/repos/ bcel https://svn.apache.org/repos/asf/commons/proper/bcel/trunk beanutils https://svn.apache.org/repos/asf/commons/proper/beanutils/trunk betwixt https://svn.apache.org/repos/asf/commons/proper/betwixt/trunk + bsf https://svn.apache.org/repos/asf/commons/proper/bsf/trunk chain https://svn.apache.org/repos/asf/commons/proper/chain/trunk cli https://svn.apache.org/repos/asf/commons/proper/cli/trunk codec https://svn.apache.org/repos/asf/commons/proper/codec/trunk Note that BSF's trunk is the 2.x codebase while 3.x where the latest releases have come from lives in a branch. I'm not sure which one should be considered the trunk in the Commons sense of trunks-proper in this case. Not sure what the BSF devs feel is correct either. I did it this way round because the site is still in trunk; this was the arrangement that seemed to cause least upheaval at the time. As it happens, the changes proposed by Rony will be in 2.x, i.e. trunk; the 3.x branch I think is stable. I'm not sure it matters too much either way. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] close() and archives/streams in an invalid state
On 17 August 2011 06:18, Stefan Bodewig bode...@apache.org wrote: On 2011-08-17, sebb wrote: On 17 August 2011 03:42, Stefan Bodewig bode...@apache.org wrote: On 2011-08-15, sebb wrote: For input, there might be a use case for leaving the stream open, in case some kind of recovery is possible. It would be useful to have a way of determining the input file pointer at the point of failure. stream.getBytesRead() or are you thinking about anything else? That would be fine. I'm not sure whether we need to do anything for that. The streams already count the bytes and you can access it when an exception occurs. We might want to revisit the exception messages whether they can include some sort of byte count. For normal users of compress I don't expect that information to be too useful, though. Most users won't be familiar with the details of the format. It may be useful for us during debugging or when bugs get reported. Yes, that was my main concern. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [compress] close() and archives/streams in an invalid state
On 2011-08-17, Honton, Charles wrote: Why guard against closing System.in? If the client application needs that sort of functionality, it should wrap the incoming stream in a proxy that doesn't delegate the close method to the underlying stream. You and I agree here - there even has been a thread about this not too long ago. Changing it would break backwards compatibility, though, something we are willing to do in a 2.x release not too far away in the future (I hope). For 1.x we prefer to keep it as it is. (A new class for commons-io?) I'm pretty sure that already exists. CloseShieldInputStream IIRC. Stefan - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Encoder / Decoder interface
Hi, Before I start, I'd love to see a binary compatible codec release with the Beider Morse code in, and for generics to be dealt with in a later release. What I'm not quite sure about is why introducing generics will necessarily cause breaking changes. It seems to me that the Encoder/Decoder interfaces are screaming out to be generified, and the current sub-interfaces should be removed unless there's a compelling reason for them e.g. if they add extra methods. It is no hardship in your code to write EncoderString, String rather than StringEncoder. I realise that in any one application it may be the case that they use only one family of encoders (e.g. String = String), but I don't see why this means we should be introducing a Java interface explicitly for this use case. We could have StringEncoder extends EncoderString, String if we wished. The problem with this is that not every EncoderString, String is a StringEncoder. It isn't a type alias. By introducing an extra interface, we're introducing an extra layer of contract. Right now StringEncoder does introduce an extra contract - it provides an over-loaded encode method specialised to String, and it is possible for implementations to do different work in the two different methods. In the specific case of the BeiderMorse encoder, the natural sig is EncoderString, SetString. I expect this is the case for some other StringEncoder implementations that deal with phonetic encodings. Would we then introduce yet another interface, FuzzyStringEncoder to capture this? All seems a bit messy to me. Java does not allow you to implement the same interface with different generic type arguments. So, you can't have Foo implements EncoderObject, Object, EncoderString, String. Because of this, you can't provide different behaviour for the two different cases. This is sort of what the current situation requires. However, look at what javap says has been generated in these scenarios. ## java public interface EncoderENC, DEC { public ENC encode(DEC dec); } ## javap public interface Encoder{ public abstract java.lang.Object encode(java.lang.Object); } ## java public interface StringEncoder extends EncoderString, String {} ## javap public interface StringEncoder extends Encoder{ } ## java public class IdE implements EncoderString, String { public String encode(String in) { return in; } } ## javap public class IdE extends java.lang.Object implements Encoder{ public IdE(); public java.lang.String encode(java.lang.String); public java.lang.Object encode(java.lang.Object); } ## java public class IdSe implements StringEncoder { public String encode(String in) { return in; } } ## javap public class IdSe extends java.lang.Object implements StringEncoder{ public IdSe(); public java.lang.String encode(java.lang.String); public java.lang.Object encode(java.lang.Object); } ## java public interface StringEncoder2 extends EncoderString, String { @Override public String encode(String in); } ## javap public interface StringEncoder2 extends Encoder{ public abstract java.lang.String encode(java.lang.String); } ## java public class IdSe2 implements StringEncoder2 { public String encode(String in) { return in; } } ## javap public class IdSe2 extends java.lang.Object implements StringEncoder2{ public IdSe2(); public java.lang.String encode(java.lang.String); public java.lang.Object encode(java.lang.Object); } So, I guess I'm wondering what the breaking changes are that definitely get introduced by generification, and if there are a significant number that can't be dealt with by a bit of judicious use of deprecation and deprecated interfaces. Matthew On 17 August 2011 06:24, Gary Gregory garydgreg...@gmail.com wrote: On Aug 16, 2011, at 23:47, sebb seb...@gmail.com wrote: On 17 August 2011 04:30, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Aug 16, 2011 at 11:14 PM, sebb seb...@gmail.com wrote: ... FYI: What would need to be reversed out of trunk for a 1.6 binary compatible with 1.5 is: [image: Error]Method 'public StringEncoderComparator()' has been removed org.apache.commons.codec.StringEncoderComparatorpublic StringEncoderComparator()[image: Error]Method 'public boolean isArrayByteBase64(byte[])' has been removed org.apache.commons.codec.binary.Base64public boolean isArrayByteBase64(byte[])[image: Error]Class org.apache.commons.codec.language.Caverphone removed org.apache.commons.codec.language.Caverphone [image: Error]Method 'public int getMaxLength()' has been removed org.apache.commons.codec.language.Soundexpublic int getMaxLength()[image: Error]Method 'public void setMaxLength(int)' has been removed org.apache.commons.codec.language.Soundexpublic void setMaxLength(int)[image: Error]Field charset is now finalorg.apache.commons.codec.net.URLCodeccharset[image: Error]Method 'public java.lang.String getEncoding()' has been removed
Re: [VOTE][DAEMON] release 1.0.6 and 1.0.7 Maven artifacts
Le 15/08/2011 20:03, sebb a écrit : Just in case anyone wants to use Maven to download the Java part of Commons Daemon (this has been requested in the past), I thought it would be useful to create and upload the Maven artifacts to the Nexus staging repo. The uploads contain source, so although the main release votes have already passed, it seems sensible to vote again on the actual Maven artifacts. I am not sure about this. What we release is mainly source code, and binaries are a convenience but seems to me less official. Also voting separately for the binaries as an afterthought is uncomfortable. Of course I do trust you to have built these artifacts properly, but how can I really be sure they correspond to the same source code we voted upon a few days ago ? Please, don't consider it as offending, I am just wondering about a process I don't master. Luc Daemon 1.0.6 == Staging area: https://repository.apache.org/content/repositories/orgapachecommons-040/commons-daemon/commons-daemon/ which was built from the tag https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_6 (r1144188) using mvn clean; mvn deploy -Prelease [ ]+1 OK to release [ ]-1 do not release, please give a reason why Daemon 1.0.7 == Staging area https://repository.apache.org/content/repositories/orgapachecommons-041/commons-daemon/commons-daemon/ which was built from the tag https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_7 (r1153351) using mvn clean; mvn deploy -Prelease [ ]+1 OK to release [ ]-1 do not release, please give a reason why Voting will remain open for the usual minimum of 72 hours. Thanks! - 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: [codec] Encoder / Decoder interface
On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote: It seems to me that the Encoder/Decoder interfaces are screaming out to be generified, and the current sub-interfaces should be removed unless there's a compelling reason for them e.g. if they add extra methods. It is no hardship in your code to write EncoderString, String rather than StringEncoder. I realise that in any one application it may be the case that they use only one family of encoders (e.g. String = String), but I don't see why this means we should be introducing a Java interface explicitly for this use case. I prefer StringEncoder to EncoderString, String. Its shorter and clearer. Overall, I'd say focus users on the concrete versions like StringEncoder. On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote: I am not a fan of these interfaces because they are not typed, Object encode(Object) is too vague now that Generics have been an option for years. The Object encode(Object) approach is still valid if the primary use case of the interface is for frameworks. In a framework, objects are generally treated as of type Object, so the API is fine. User code should use concrete versions. Stephen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Encoder / Decoder interface
On 17 August 2011 13:58, Stephen Colebourne scolebou...@joda.org wrote: The Object encode(Object) approach is still valid if the primary use case of the interface is for frameworks. In a framework, objects are generally treated as of type Object, so the API is fine. User code should use concrete versions. In the case of ENC encode(DEC), the framework sees Object encode(Object), as this is the erased type. The framework is happy and Java code referring to the Encoder interface (directly or indirectly) is type-safe (baring casts which we can't do much about). Matthew Stephen -- Dr Matthew Pocock Visitor, School of Computing Science, Newcastle University mailto: turingatemyhams...@gmail.com gchat: turingatemyhams...@gmail.com msn: matthew_poc...@yahoo.co.uk irc.freenode.net: drdozer tel: (0191) 2566550 mob: +447535664143
Re: [VOTE][DAEMON] release 1.0.6 and 1.0.7 Maven artifacts
On 17 August 2011 13:50, Luc Maisonobe luc.maison...@free.fr wrote: Le 15/08/2011 20:03, sebb a écrit : Just in case anyone wants to use Maven to download the Java part of Commons Daemon (this has been requested in the past), I thought it would be useful to create and upload the Maven artifacts to the Nexus staging repo. The uploads contain source, so although the main release votes have already passed, it seems sensible to vote again on the actual Maven artifacts. I am not sure about this. What we release is mainly source code, and binaries are a convenience but seems to me less official. Also voting separately for the binaries as an afterthought is uncomfortable. Of course I do trust you to have built these artifacts properly, but how can I really be sure they correspond to the same source code we voted upon a few days ago ? They were built from the same tags (listed below), which you can compare against the source jar. Please, don't consider it as offending, I am just wondering about a process I don't master. Not sure I understand how this is different from the previous Daemon votes, apart from the fact that the source/binary jars only relate to the Java subset of the original vote. It's still possible to check the artifact contents, sigs, hashes, and it's still possible to check that the source jar only contains source from the tag. Luc Daemon 1.0.6 == Staging area: https://repository.apache.org/content/repositories/orgapachecommons-040/commons-daemon/commons-daemon/ which was built from the tag https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_6 (r1144188) using mvn clean; mvn deploy -Prelease [ ]+1 OK to release [ ]-1 do not release, please give a reason why Daemon 1.0.7 == Staging area https://repository.apache.org/content/repositories/orgapachecommons-041/commons-daemon/commons-daemon/ which was built from the tag https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_7 (r1153351) using mvn clean; mvn deploy -Prelease [ ]+1 OK to release [ ]-1 do not release, please give a reason why Voting will remain open for the usual minimum of 72 hours. Thanks! - 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: [codec] Encoder / Decoder interface
Hi Matthew, On Wed, Aug 17, 2011 at 8:44 AM, Matthew Pocock turingatemyhams...@gmail.com wrote: Hi, Before I start, I'd love to see a binary compatible codec release with the Beider Morse code in, and for generics to be dealt with in a later release. I think this is where we are going, see previous emails and threads. What I'm not quite sure about is why introducing generics will necessarily cause breaking changes. I can break things depending on the new design... we'll have to all discuss. See the branch in SVN for my first cut. https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics It seems to me that the Encoder/Decoder interfaces are screaming out to be generified, Yes! :) and the current sub-interfaces should be removed unless there's a compelling reason for them e.g. if they add extra methods. It is no hardship in your code to write EncoderString, String rather than StringEncoder. I realise that in any one application it may be the case that they use only one family of encoders (e.g. String = String), but I don't see why this means we should be introducing a Java interface explicitly for this use case. I had not thought about it that way and I do like the idea since there are no new methods there. If you look at the branch I have: interface EncoderI,O with O encode(I) and interface SymmerticEncoderT extends EncoderT, T interface StringEncoder extends SymmerticEncoderString I could see doing away with StringEncoder. This would hopelessly break compatibility but I like it because it uses generics in the most natural way IMO. We could have StringEncoder extends EncoderString, String if we wished. The problem with this is that not every EncoderString, String is a StringEncoder. It isn't a type alias. By introducing an extra interface, we're introducing an extra layer of contract. Right now StringEncoder does introduce an extra contract - it provides an over-loaded encode method specialised to String, and it is possible for implementations to do different work in the two different methods. In the specific case of the BeiderMorse encoder, the natural sig is EncoderString, SetString. I expect this is the case for some other StringEncoder implementations that deal with phonetic encodings. Would we then introduce yet another interface, FuzzyStringEncoder to capture this? I hope not! All seems a bit messy to me. Java does not allow you to implement the same interface with different generic type arguments. So, you can't have Foo implements EncoderObject, Object, EncoderString, String. Yep, that's the only problem I ran into when adding generics to the branch Because of this, you can't provide different behaviour for the two different cases. This is sort of what the current situation requires. However, look at what javap says has been generated in these scenarios. AH, it looks like you decompiled the branch ;) Gary ## java public interface EncoderENC, DEC { public ENC encode(DEC dec); } ## javap public interface Encoder{ public abstract java.lang.Object encode(java.lang.Object); } ## java public interface StringEncoder extends EncoderString, String {} ## javap public interface StringEncoder extends Encoder{ } ## java public class IdE implements EncoderString, String { public String encode(String in) { return in; } } ## javap public class IdE extends java.lang.Object implements Encoder{ public IdE(); public java.lang.String encode(java.lang.String); public java.lang.Object encode(java.lang.Object); } ## java public class IdSe implements StringEncoder { public String encode(String in) { return in; } } ## javap public class IdSe extends java.lang.Object implements StringEncoder{ public IdSe(); public java.lang.String encode(java.lang.String); public java.lang.Object encode(java.lang.Object); } ## java public interface StringEncoder2 extends EncoderString, String { @Override public String encode(String in); } ## javap public interface StringEncoder2 extends Encoder{ public abstract java.lang.String encode(java.lang.String); } ## java public class IdSe2 implements StringEncoder2 { public String encode(String in) { return in; } } ## javap public class IdSe2 extends java.lang.Object implements StringEncoder2{ public IdSe2(); public java.lang.String encode(java.lang.String); public java.lang.Object encode(java.lang.Object); } So, I guess I'm wondering what the breaking changes are that definitely get introduced by generification, and if there are a significant number that can't be dealt with by a bit of judicious use of deprecation and deprecated interfaces. Matthew On 17 August 2011 06:24, Gary Gregory garydgreg...@gmail.com wrote: On Aug 16, 2011, at 23:47, sebb seb...@gmail.com wrote: On 17 August 2011 04:30, Gary Gregory garydgreg...@gmail.com wrote: On Tue, Aug 16, 2011 at 11:14
Re: [codec] Encoder / Decoder interface
Hi All: On Wed, Aug 17, 2011 at 8:58 AM, Stephen Colebourne scolebou...@joda.orgwrote: On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote: It seems to me that the Encoder/Decoder interfaces are screaming out to be generified, and the current sub-interfaces should be removed unless there's a compelling reason for them e.g. if they add extra methods. It is no hardship in your code to write EncoderString, String rather than StringEncoder. I realise that in any one application it may be the case that they use only one family of encoders (e.g. String = String), but I don't see why this means we should be introducing a Java interface explicitly for this use case. I prefer StringEncoder to EncoderString, String. Its shorter and clearer. What about SymmetricEncoderString? [Leaving aside bin compat for this chat...] I'm not sure I buy the argument for keeping StringEncoder in a generified codec2/3. For example, Strings are very common if not the most common kind of List but there is no java.util.StringList and so on. Overall, I'd say focus users on the concrete versions like StringEncoder. On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote: I am not a fan of these interfaces because they are not typed, Object encode(Object) is too vague now that Generics have been an option for years. The Object encode(Object) approach is still valid if the primary use case of the interface is for frameworks. In a framework, objects are generally treated as of type Object, so the API is fine. User code should use concrete versions. With a generics codec, a f/w can still use Object, it has to downcast but it is possible/ugly. Cheers! Gary Stephen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [codec] Encoder / Decoder interface
On 17 August 2011 13:58, Stephen Colebourne scolebou...@joda.org wrote: On 17 August 2011 13:44, Matthew Pocock turingatemyhams...@gmail.com wrote: It seems to me that the Encoder/Decoder interfaces are screaming out to be generified, and the current sub-interfaces should be removed unless there's a compelling reason for them e.g. if they add extra methods. It is no hardship in your code to write EncoderString, String rather than StringEncoder. I realise that in any one application it may be the case that they use only one family of encoders (e.g. String = String), but I don't see why this means we should be introducing a Java interface explicitly for this use case. I prefer StringEncoder to EncoderString, String. Its shorter and clearer. Overall, I'd say focus users on the concrete versions like StringEncoder. If StringEncoder is a non-generic interface it also makes it possible to combine interfaces in classes, as is done currently. Not sure this is possible with all-generic interfaces. On 16 August 2011 21:38, Gary Gregory garydgreg...@gmail.com wrote: I am not a fan of these interfaces because they are not typed, Object encode(Object) is too vague now that Generics have been an option for years. The Object encode(Object) approach is still valid if the primary use case of the interface is for frameworks. In a framework, objects are generally treated as of type Object, so the API is fine. User code That's useful to know (I've not used frameworks) should use concrete versions. +1 Stephen - 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
[continuum] BUILD FAILURE: Apache Commons - Commons Compress - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=11377projectId=64 Build statistics: State: Failed Previous State: Ok Started at: Wed 17 Aug 2011 14:22:43 + Finished at: Wed 17 Aug 2011 14:23:04 + Total time: 21s Build Trigger: Schedule Build Number: 92 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_24 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: en_AU, platform encoding: UTF-8 OS name: linux version: 2.6.32-31-server arch: amd64 Family: unix SCM Changes: Changed: bodewig @ Wed 17 Aug 2011 14:07:12 + Comment: make extraction tests pass for dump. COMPRESS-132 Files changed: /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveEntry.java ( 1158723 ) /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress/archivers/dump/DumpArchiveInputStream.java ( 1158723 ) /commons/proper/compress/trunk/src/test/java/org/apache/commons/compress/archivers/DumpTestCase.java ( 1158723 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 228 Failures: 2 Errors: 0 Success Rate: 99 Total time: 1.2810001 Test Failures: DumpTestCase testCheckArchive : junit.framework.AssertionFailedError junit.framework.AssertionFailedError: extraction failed: . at junit.framework.Assert.fail(Assert.java:47) at org.apache.commons.compress.AbstractTestCase.checkArchiveContent(AbstractTestCase.java:341) at org.apache.commons.compress.AbstractTestCase.checkArchiveContent(AbstractTestCase.java:301) at org.apache.commons.compress.archivers.DumpTestCase.checkDumpArchive(DumpTestCase.java:113) at org.apache.commons.compress.archivers.DumpTestCase.testCheckArchive(DumpTestCase.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:243) at junit.framework.TestSuite.run(TestSuite.java:238) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at $Proxy0.invoke(Unknown Source) at
Re: [Math] iterator and sparseIterator in RealVector hierarchy
On Wed, Aug 17, 2011 at 4:44 AM, Gilles Sadowski gil...@harfang.homelinux.org wrote: It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. Do you mean that the matrix is stateless (each call to get generates a new value)? Yes. And I would also typically expect it to be immutable although changing p is a reasonable thing to do (I just prefer immutable objects where practical). If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. As far as I understand, the sparseness test is an indicator that there is an optimized way to iterate over the entries (faster than a loop over all the indices) or that not all entries are explicitly stored. Is that correct? Yes. If so, this is tied to the layout of the matrix, i.e. the type (which can change depending on an input value, such as p above). Yes. However, once it is created, its type/implementation is either dense or sparse. It depends on whether setP() is supported. If the setter is there, then density can even change after construction. [...] I'm wondering whether this leads again to the issue of CM being a framework for everyone to build on, or if its data structures are mostly intended for internal use, so that the algorithms it provides are most efficient. Well, it *is* open source (so they say). That kind of indicates that it should be relatively easy for people to provide code. Also, I find that even the idea of this dichotomy is a bit of a mirage. Providing a good extensible design often gives faster code down the way a bit.
Re: [Math] iterator and sparseIterator in RealVector hierarchy
Arne, Please read the thread again. I am providing an example of how I think things *should* be. The point of doing so is that things are not that way now. Telling me that they are not that way is pretty redundant. On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote: Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for sparseIterator ? Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. This matrix and siblings is very important in compressed sensing and stochastic projection algorithms. On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/16/11 4:46 AM, Gilles Sadowski wrote: Hi. I understood what he was suggesting. I still disagree. Dynamic dispatch and non-lattice typing structure is still required to make this all work. Java doesn't really do that. Pretending that what Java does is sufficient is hammer-looking-for-a-nail, not solving the problems at hand. Maybe that *I* don't understand what you are hinting at. Sorry for being dense. [Although that seems appropriate in this discussion :-).] Polymorphism provides dynamic dispatch, overloading does not; that's why my proposition is that when you manipulate unknown types, those should come as this, not as the argument of the method. What's wrong with that? As for hammer-looking-for-a-nail, I also don't see what you mean: What is the problem? I guess that there are lots of applications who never need to know about sparse vectors/matrices. In those cases, the added complexity is not a feature. The issue reported contends that the current design in CM can cause problems for dense implementations. I'm not even sure that the current design is usable for the type of applications that make heavy use of sparseness. Those are problems, IMHO. I have been out of pocket the last couple of days and may not have time to dig into this until late tonight, but I agree with Gilles that we need to get the conversation here more concrete. I know we discussed this before and Ted and others had good examples justifying the current setup. Can we revisit these, please? What would be great would be some examples both from the perspective of the [math] developer looking to add a new or specialized class and [math] users writing code that leverages the setup. Phil Gilles On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski gsterijev...@gmail.comwrote: Forgive me for pushing my nose under the tent... I couldn't resist. I think Gilles is saying that each specialization of the matrix/vector objects would need to support pre (and post) multiplication with a dense. So the type issue would not be problematic. On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning ted.dunn...@gmail.com wrote: No. You can't. This is because the type is lost as you enter the generic library. On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: They know that their own object is dense, but they don't know what kind of input they were given. They should still run fast if the input is sparse. Couldn't we still rely on polymorphism by implementing preTimes: unknown.preTimes(dense) - 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:
[POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque
Eclipse complains about all the @inheritDoc tags in LinkedBlockingDeque. AFAICT, @inheritDoc is allowed in @throws, but only if the method has something to inherit from, i.e.. it overrides a super-class method or implements an interface (Java 1.6+) It does not inherit from the Throwable, which was perhaps the intention? Oracle Java 1.5 is happy to allow @inheritDoc in the add() method - because that overrides - but Eclipse complains. [Looks like bug in Eclipse javadoc handling] However, neither Oracle nor Eclipse allow the tag if there is no parent, so I propose to remove such tags. OK? - 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 All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.comwrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/ (revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-javadoc.jar commons-vfs2-examples-2.0-sources.jar.asc commons-vfs2-examples-2.0.pom commons-vfs2-examples-2.0-tests.jar commons-vfs2-examples-2.0-tests.jar.asc commons-vfs2-examples-2.0.jar.asc commons-vfs2-examples-2.0.pom.asc commons-vfs2-examples-2.0-javadoc.jar.asc commons-vfs2-examples-2.0.jar commons-vfs2-examples-2.0-sources.jar commons-vfs2-project-2.0.pom.asc commons-vfs2-project-2.0.pom commons-vfs2-sandbox-2.0.pom.asc commons-vfs2-sandbox-2.0-sources.jar.asc commons-vfs2-sandbox-2.0-test-sources.jar.asc commons-vfs2-sandbox-2.0.jar commons-vfs2-sandbox-2.0-javadoc.jar commons-vfs2-sandbox-2.0-test-sources.jar commons-vfs2-sandbox-2.0.jar.asc commons-vfs2-sandbox-2.0-sources.jar commons-vfs2-sandbox-2.0-javadoc.jar.asc commons-vfs2-sandbox-2.0-tests.jar.asc commons-vfs2-sandbox-2.0-tests.jar commons-vfs2-sandbox-2.0.pom
Re: [POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque
+1, who's on first again? Gary On Wed, Aug 17, 2011 at 11:09 AM, sebb seb...@gmail.com wrote: Eclipse complains about all the @inheritDoc tags in LinkedBlockingDeque. AFAICT, @inheritDoc is allowed in @throws, but only if the method has something to inherit from, i.e.. it overrides a super-class method or implements an interface (Java 1.6+) It does not inherit from the Throwable, which was perhaps the intention? Oracle Java 1.5 is happy to allow @inheritDoc in the add() method - because that overrides - but Eclipse complains. [Looks like bug in Eclipse javadoc handling] However, neither Oracle nor Eclipse allow the tag if there is no parent, so I propose to remove such tags. OK? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
Re: [POOL] @inheritDoc tags for @throws clauses in LinkedBlockingDeque
On 17 August 2011 16:09, sebb seb...@gmail.com wrote: Eclipse complains about all the @inheritDoc tags in LinkedBlockingDeque. AFAICT, @inheritDoc is allowed in @throws, but only if the method has something to inherit from, i.e.. it overrides a super-class method or implements an interface (Java 1.6+) It does not inherit from the Throwable, which was perhaps the intention? Oracle Java 1.5 is happy to allow @inheritDoc in the add() method - because that overrides - but Eclipse complains. [Looks like bug in Eclipse javadoc handling] Actually, just discovered that Oracle Javadoc has problems too - it does not complain about the tag for overriding methods, but does not import the details either - the generated Javadoc for add(E) contains Overrides: add in class AbstractQueueE Throws: {@inheritDoc} which is not at all helpful ... So it now looks like all the inheritDoc tags should be removed from throws clauses. However, neither Oracle nor Eclipse allow the tag if there is no parent, so I propose to remove such tags. OK? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] iterator and sparseIterator in RealVector hierarchy
Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning: Arne, Please read the thread again. I am providing an example of how I think things *should* be. OK. if I understand you right: isSparse() should be added to RealVector and the interface SparseRealVector can be dropped? The point of doing so is that things are not that way now. Telling me that they are not that way is pretty redundant. On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote: Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for sparseIterator ? Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. This matrix and siblings is very important in compressed sensing and stochastic projection algorithms. On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/16/11 4:46 AM, Gilles Sadowski wrote: Hi. I understood what he was suggesting. I still disagree. Dynamic dispatch and non-lattice typing structure is still required to make this all work. Java doesn't really do that. Pretending that what Java does is sufficient is hammer-looking-for-a-nail, not solving the problems at hand. Maybe that *I* don't understand what you are hinting at. Sorry for being dense. [Although that seems appropriate in this discussion :-).] Polymorphism provides dynamic dispatch, overloading does not; that's why my proposition is that when you manipulate unknown types, those should come as this, not as the argument of the method. What's wrong with that? As for hammer-looking-for-a-nail, I also don't see what you mean: What is the problem? I guess that there are lots of applications who never need to know about sparse vectors/matrices. In those cases, the added complexity is not a feature. The issue reported contends that the current design in CM can cause problems for dense implementations. I'm not even sure that the current design is usable for the type of applications that make heavy use of sparseness. Those are problems, IMHO. I have been out of pocket the last couple of days and may not have time to dig into this until late tonight, but I agree with Gilles that we need to get the conversation here more concrete. I know we discussed this before and Ted and others had good examples justifying the current setup. Can we revisit these, please? What would be great would be some examples both from the perspective of the [math] developer looking to add a new or specialized class and [math] users writing code that leverages the setup. Phil Gilles On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski gsterijev...@gmail.comwrote: Forgive me for pushing my nose under the tent... I couldn't resist. I think Gilles is saying that each specialization of the matrix/vector objects would need to support pre (and post) multiplication with a dense. So the type issue would not be problematic. On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning ted.dunn...@gmail.com wrote: No. You can't. This is because the type is lost as you enter the generic library. On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: They know that their own object is dense, but they don't know what kind of input they were given. They should still run fast if the input is sparse. Couldn't we still rely on polymorphism by implementing preTimes: unknown.preTimes(dense) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:
Re: [Math] iterator and sparseIterator in RealVector hierarchy
I think that all vectors and matrices should be able to answer the question about whether they are sparse and they should support sparse iterators, defaulting to the normal iterators in the general case. So yes to the first question. This allows the application programmer to be much less concerned about whether they are using a sparse or dense matrix without losing much performance, if any. The second question I think is much less clear. It might well be a good idea to keep the interface to help the compiler in cases where the programmer knows which general class of matrix they have. On Wed, Aug 17, 2011 at 8:29 AM, Arne Ploese aplo...@gmx.de wrote: Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning: Arne, Please read the thread again. I am providing an example of how I think things *should* be. OK. if I understand you right: isSparse() should be added to RealVector and the interface SparseRealVector can be dropped? The point of doing so is that things are not that way now. Telling me that they are not that way is pretty redundant. On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote: Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for sparseIterator ? Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. This matrix and siblings is very important in compressed sensing and stochastic projection algorithms. On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/16/11 4:46 AM, Gilles Sadowski wrote: Hi. I understood what he was suggesting. I still disagree. Dynamic dispatch and non-lattice typing structure is still required to make this all work. Java doesn't really do that. Pretending that what Java does is sufficient is hammer-looking-for-a-nail, not solving the problems at hand. Maybe that *I* don't understand what you are hinting at. Sorry for being dense. [Although that seems appropriate in this discussion :-).] Polymorphism provides dynamic dispatch, overloading does not; that's why my proposition is that when you manipulate unknown types, those should come as this, not as the argument of the method. What's wrong with that? As for hammer-looking-for-a-nail, I also don't see what you mean: What is the problem? I guess that there are lots of applications who never need to know about sparse vectors/matrices. In those cases, the added complexity is not a feature. The issue reported contends that the current design in CM can cause problems for dense implementations. I'm not even sure that the current design is usable for the type of applications that make heavy use of sparseness. Those are problems, IMHO. I have been out of pocket the last couple of days and may not have time to dig into this until late tonight, but I agree with Gilles that we need to get the conversation here more concrete. I know we discussed this before and Ted and others had good examples justifying the current setup. Can we revisit these, please? What would be great would be some examples both from the perspective of the [math] developer looking to add a new or specialized class and [math] users writing code that leverages the setup. Phil Gilles On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski gsterijev...@gmail.comwrote: Forgive me for pushing my nose under the tent... I couldn't resist. I think Gilles is saying that each specialization of the matrix/vector objects would need to support pre (and post) multiplication with a dense. So the type issue would not be
[math] StorelessCovariance
I am workin on the StorelessCovariance per jira MATH-449. However, I'm having a hard time using subversion via Netbeans. I have successfully created the new classes and a JUnit test. However, when I run the test I get the following message, caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/TestUtils Any help would be appreciated. I have a lot to contribute to commons math but my lack of experience with subversion is really hindering me. Thanks, Patrick - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] StorelessCovariance
On 8/17/11 9:15 AM, Patrick Meyer wrote: caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/TestUtils First of all, THANKS for working on this! This may not be what you want to hear or the fashionable response, but I personally never use IDE integrated thingies for exactly this kind of reason. Most likely you have some kind of classpath or compiled class cleanup problem. Try cleaning everything and starting with a fresh checkout and also checking that the IDE is not bringing in an old [math] jar somehow. As I said, because of this kind of silliness, I always just run svn co or svn up from the command line and then mvn clean test from the checked out trunk. Then svn diff newPatch to create patches or inspect changes before committing. Using -Dtest=ClassNameOfTest is convenient if you don't want to run all of the tests. Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] StorelessCovariance
I am workin on the StorelessCovariance per jira MATH-449. However, I'm having a hard time using subversion via Netbeans. I have successfully created the new classes and a JUnit test. However, when I run the test I get the following message, caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/TestUtils Any help would be appreciated. I have a lot to contribute to commons math but my lack of experience with subversion is really hindering me. Thanks, Patrick - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain] Apache Chain v2 Proof of Concept
Hi Matt and Simo, I've attached the patch to the bug and fixed the issues mentioned with faces. What other steps do I need to do now? Thanks, -Elijah On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson gudnabr...@gmail.com wrote: Hi, Elijah-- I am neither a develop nor even a user of chain, so my comments will be high-level. Firstly, by all means upgrade to whatever JUnit 4 release version you like, e.g. 4.8.2. Next, I personally am a big fan of Mockito, so no complaints here on that account. I can't guarantee noone else would complain, but [chain] has been fairly unloved for a good while. As for JSF 2.1, is there something this achieves that wouldn't be equally well accomplished by simply upgrading to 2.0? This would give [chain]'s JSF support (which I personally hadn't realized existed) a potentially better combination of doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest possible applicability. Finally, as you don't seem to be a committer your final submission in this regard would be best recommended in the form of a JIRA issue, and your patches in (albeit large) patch form. In addition to this, the scope of these changes indicates it best IMO that you submit an Individual Contributor License Agreement governing your contributions to the ASF. See http://www.apache.org/licenses/#clas for details on how to do this. Regards and welcome, Matt On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic eli...@zupancic.name wrote: I've just finished my proof of concept for an upgrade to Apache chain. I would love to get this into a svn branch. I'm not quite sure what the procedure is to do that, but the code can be found here for review: http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz And here is a diff: http://elijah.zupancic.name/projects/uber-diff At a high level, I have incorporated the following features in this proof of concept: * Global upgrade to the JDK 1.5 * Added @Override annotations * Upgraded to the Servlet 2.5 API * Upgraded to the Faces 2.1 API * Upgraded to the Portlet 2.0 API * Upgraded the Maven Parent POM version * Added generics support to Command so that Command's API looks like: public interface CommandT extends Context { ... boolean execute(T context) throws Exception; } * Servlet and Portlet packages now provide Genericized APIs. * All dicey changes have been marked with a comment with my name: (elijah) More or less the work to updated Chain was straight forward albeit time consuming. If everyone is on board for this update, I would like to upgrade the test cases to use a new version of JUnit. However, this leads to a few questions: * What version of JUnit should I use? * Would it be ok to use Mockito for mocking instead of the home grown mocking classes already contained in the project? Please let me know what you think. Getting this far has been a couple weeks worth of on and off work. Thanks, -Elijah - 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: [chain] Apache Chain v2 Proof of Concept
Be patient, while not being so patient that you allow us to forget it. Matt On Wed, Aug 17, 2011 at 12:01 PM, Elijah Zupancic eli...@zupancic.name wrote: Hi Matt and Simo, I've attached the patch to the bug and fixed the issues mentioned with faces. What other steps do I need to do now? Thanks, -Elijah On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson gudnabr...@gmail.com wrote: Hi, Elijah-- I am neither a develop nor even a user of chain, so my comments will be high-level. Firstly, by all means upgrade to whatever JUnit 4 release version you like, e.g. 4.8.2. Next, I personally am a big fan of Mockito, so no complaints here on that account. I can't guarantee noone else would complain, but [chain] has been fairly unloved for a good while. As for JSF 2.1, is there something this achieves that wouldn't be equally well accomplished by simply upgrading to 2.0? This would give [chain]'s JSF support (which I personally hadn't realized existed) a potentially better combination of doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest possible applicability. Finally, as you don't seem to be a committer your final submission in this regard would be best recommended in the form of a JIRA issue, and your patches in (albeit large) patch form. In addition to this, the scope of these changes indicates it best IMO that you submit an Individual Contributor License Agreement governing your contributions to the ASF. See http://www.apache.org/licenses/#clas for details on how to do this. Regards and welcome, Matt On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic eli...@zupancic.name wrote: I've just finished my proof of concept for an upgrade to Apache chain. I would love to get this into a svn branch. I'm not quite sure what the procedure is to do that, but the code can be found here for review: http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz And here is a diff: http://elijah.zupancic.name/projects/uber-diff At a high level, I have incorporated the following features in this proof of concept: * Global upgrade to the JDK 1.5 * Added @Override annotations * Upgraded to the Servlet 2.5 API * Upgraded to the Faces 2.1 API * Upgraded to the Portlet 2.0 API * Upgraded the Maven Parent POM version * Added generics support to Command so that Command's API looks like: public interface CommandT extends Context { ... boolean execute(T context) throws Exception; } * Servlet and Portlet packages now provide Genericized APIs. * All dicey changes have been marked with a comment with my name: (elijah) More or less the work to updated Chain was straight forward albeit time consuming. If everyone is on board for this update, I would like to upgrade the test cases to use a new version of JUnit. However, this leads to a few questions: * What version of JUnit should I use? * Would it be ok to use Mockito for mocking instead of the home grown mocking classes already contained in the project? Please let me know what you think. Getting this far has been a couple weeks worth of on and off work. Thanks, -Elijah - 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: [chain] Apache Chain v2 Proof of Concept
BTW, please don't take the previous response as indicating any negativity on my part. Feel free to prod us as long as possible, at reasonable frequency. Matt On Wed, Aug 17, 2011 at 12:04 PM, Matt Benson gudnabr...@gmail.com wrote: Be patient, while not being so patient that you allow us to forget it. Matt On Wed, Aug 17, 2011 at 12:01 PM, Elijah Zupancic eli...@zupancic.name wrote: Hi Matt and Simo, I've attached the patch to the bug and fixed the issues mentioned with faces. What other steps do I need to do now? Thanks, -Elijah On Mon, Aug 15, 2011 at 6:22 AM, Matt Benson gudnabr...@gmail.com wrote: Hi, Elijah-- I am neither a develop nor even a user of chain, so my comments will be high-level. Firstly, by all means upgrade to whatever JUnit 4 release version you like, e.g. 4.8.2. Next, I personally am a big fan of Mockito, so no complaints here on that account. I can't guarantee noone else would complain, but [chain] has been fairly unloved for a good while. As for JSF 2.1, is there something this achieves that wouldn't be equally well accomplished by simply upgrading to 2.0? This would give [chain]'s JSF support (which I personally hadn't realized existed) a potentially better combination of doing-things-that-couldn't-easily-be-done-with-older-APIs vs. broadest possible applicability. Finally, as you don't seem to be a committer your final submission in this regard would be best recommended in the form of a JIRA issue, and your patches in (albeit large) patch form. In addition to this, the scope of these changes indicates it best IMO that you submit an Individual Contributor License Agreement governing your contributions to the ASF. See http://www.apache.org/licenses/#clas for details on how to do this. Regards and welcome, Matt On Sun, Aug 14, 2011 at 5:13 PM, Elijah Zupancic eli...@zupancic.name wrote: I've just finished my proof of concept for an upgrade to Apache chain. I would love to get this into a svn branch. I'm not quite sure what the procedure is to do that, but the code can be found here for review: http://elijah.zupancic.name/projects/commons-chain-v2-proof-of-concept.tar.gz And here is a diff: http://elijah.zupancic.name/projects/uber-diff At a high level, I have incorporated the following features in this proof of concept: * Global upgrade to the JDK 1.5 * Added @Override annotations * Upgraded to the Servlet 2.5 API * Upgraded to the Faces 2.1 API * Upgraded to the Portlet 2.0 API * Upgraded the Maven Parent POM version * Added generics support to Command so that Command's API looks like: public interface CommandT extends Context { ... boolean execute(T context) throws Exception; } * Servlet and Portlet packages now provide Genericized APIs. * All dicey changes have been marked with a comment with my name: (elijah) More or less the work to updated Chain was straight forward albeit time consuming. If everyone is on board for this update, I would like to upgrade the test cases to use a new version of JUnit. However, this leads to a few questions: * What version of JUnit should I use? * Would it be ok to use Mockito for mocking instead of the home grown mocking classes already contained in the project? Please let me know what you think. Getting this far has been a couple weeks worth of on and off work. Thanks, -Elijah - 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
[continuum] BUILD FAILURE: Apache Commons - Commons Pool - Default Maven 2 Build Definition (Java 1.5)
Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=11393projectId=98 Build statistics: State: Failed Previous State: Ok Started at: Wed 17 Aug 2011 17:22:07 + Finished at: Wed 17 Aug 2011 17:22:15 + Total time: 7s Build Trigger: Schedule Build Number: 106 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_24 Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_24 Java home: /usr/lib/jvm/java-6-sun-1.6.0.24/jre Default locale: en_AU, platform encoding: UTF-8 OS name: linux version: 2.6.32-31-server arch: amd64 Family: unix SCM Changes: Changed: markt @ Wed 17 Aug 2011 17:03:35 + Comment: POOL-98. Add additional attributes for moniroting (also available via JMX) Files changed: /commons/proper/pool/trunk/src/changes/changes.xml ( 1158831 ) /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java ( 1158831 ) /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPoolMBean.java ( 1158831 ) /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java ( 1158831 ) /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPoolMBean.java ( 1158831 ) /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/PooledObject.java ( 1158831 ) Changed: markt @ Wed 17 Aug 2011 17:10:25 + Comment: Ensure MBeans are de-registered on pool close. Files changed: /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java ( 1158834 ) /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericObjectPool.java ( 1158834 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Default Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 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
Re: [math] StorelessCovariance
Hi Patrick, Le 17/08/2011 18:15, Patrick Meyer a écrit : I am workin on the StorelessCovariance per jira MATH-449. However, I'm having a hard time using subversion via Netbeans. I have successfully created the new classes and a JUnit test. However, when I run the test I get the following message, caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/TestUtils Do you have a complete implementation of JUnit in your classpath or only the top level API ? It seems similar to this: http://www.andrejkoelewijn.com/wp/2010/03/04/absent-code-attribute-in-method-that-is-not-native-or-abstract/ or this http://dominikdorn.com/2010/05/maven-junit-classformaterror-absent-code-attribute/ and hence elated to API and implementation separation. Apache Commons Math does not have any runtime dependency and the only test time dependency is JUnit. Luc Any help would be appreciated. I have a lot to contribute to commons math but my lack of experience with subversion is really hindering me. Thanks, Patrick - 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] iterator and sparseIterator in RealVector hierarchy
So what exactly is the meaning of isSparse? * the vector at hand implements some kind of sparse storage? I.E: OpenMapRealVector or * the vector is actually sparsely filled (then what is sparse anyway 10%, 50%, 90%?) in this case a SparserelVector interface is useless for the compiler. My suggestion is: ArrayRealVector implements a sparse iterator which returns only values != 0? Having the backing storage implementation open, one could think of: * isArray * isBanded * isSymetrical * isDiagonal as additional markers or put the whole thing in an enum or EnumSet? Am Mittwoch, den 17.08.2011, 08:51 -0700 schrieb Ted Dunning: I think that all vectors and matrices should be able to answer the question about whether they are sparse and they should support sparse iterators, defaulting to the normal iterators in the general case. So yes to the first question. This allows the application programmer to be much less concerned about whether they are using a sparse or dense matrix without losing much performance, if any. The second question I think is much less clear. It might well be a good idea to keep the interface to help the compiler in cases where the programmer knows which general class of matrix they have. On Wed, Aug 17, 2011 at 8:29 AM, Arne Ploese aplo...@gmx.de wrote: Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning: Arne, Please read the thread again. I am providing an example of how I think things *should* be. OK. if I understand you right: isSparse() should be added to RealVector and the interface SparseRealVector can be dropped? The point of doing so is that things are not that way now. Telling me that they are not that way is pretty redundant. On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote: Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for sparseIterator ? Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor of this matrix. This works in Mahout for instance by having the default operations in AbstractMatrix test for sparseness of left or right operands and do the right thing. Obviously, a type test will not tell you whether this matrix is sparse or not. This matrix and siblings is very important in compressed sensing and stochastic projection algorithms. On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/16/11 4:46 AM, Gilles Sadowski wrote: Hi. I understood what he was suggesting. I still disagree. Dynamic dispatch and non-lattice typing structure is still required to make this all work. Java doesn't really do that. Pretending that what Java does is sufficient is hammer-looking-for-a-nail, not solving the problems at hand. Maybe that *I* don't understand what you are hinting at. Sorry for being dense. [Although that seems appropriate in this discussion :-).] Polymorphism provides dynamic dispatch, overloading does not; that's why my proposition is that when you manipulate unknown types, those should come as this, not as the argument of the method. What's wrong with that? As for hammer-looking-for-a-nail, I also don't see what you mean: What is the problem? I guess that there are lots of applications who never need to know about sparse vectors/matrices. In those cases, the added complexity is not a feature. The issue reported contends that the current design in CM can cause problems for dense implementations. I'm not even sure that the current design is usable for the type of applications that make heavy use of sparseness. Those are problems, IMHO. I have been out of pocket the last couple of days and may not have time to dig into this until late tonight, but I agree with Gilles that we need to get the conversation here more concrete. I know we
Re: [Vote] Release Commons VFS 2.0
What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/(revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-javadoc.jar
Re: [Vote] Release Commons VFS 2.0
Oh - and if for some non-obvious reason you want to create the distribution jars when you do the build you can run mvn -P apache-release clean install. On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oops. That should be mvn site:stage-deploy. Ralph On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/(revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at:
Re: [Math] iterator and sparseIterator in RealVector hierarchy
I would think neither. I think it should mean that the sparseIterator will be enough faster than the dense iterator to make it worth using. The indication doesn't have to be be crisp or even always quite correct. Thus, a densely filled OpenMapReal might just return true because that usage is out of the ordinary. Regarding what the sparseIterator returns, skipping zeroes is a fine idea, but the contract should really be that all non-zeros will be returned rather than no zeros will be returned. There should be flexibility to return zero values if that is much more convenient, but there should be no case where a non-zero is missed. Regarding the additional indicators, these are occasionally useful in particular cases, but many of those special cases actually work out just as well if you simply treat them as sparse. As an example, multiplication by a diagonal matrix can be special cased, but simply iterating over the non-zeros (i.e. the diagonal) is just as good. Matrix power is a counter-example where the computation can be reduced to element-wise power for diagonal, but not for sparse. Even so, the sparse implementation is surprisingly competitive even there especially for small powers if you have a special sparse-sparse multiply. Mahout has an additional indicator function that tells whether sparseIterator returns items in a sequential order which can reduce many of these cases to a merge. For banded arrays, the economies available beyond simple sparse algorithms are even more limited. Symmetric and triangular matrices also have special properties but it is hard to decide what is really important there. Many of the special operations for these kinds of matrix are subject to solving by overloads instead of indicators since we aren't dealing with binary operations. For example, left and right inverse multiplication with triangular matrices is handled by normal single dispatch and qualifying an argument for real Cholesky decomposition is specific to the Cholesky decomposition itself. On Wed, Aug 17, 2011 at 11:28 AM, Arne Ploese aplo...@gmx.de wrote: So what exactly is the meaning of isSparse? * the vector at hand implements some kind of sparse storage? I.E: OpenMapRealVector or * the vector is actually sparsely filled (then what is sparse anyway 10%, 50%, 90%?) in this case a SparserelVector interface is useless for the compiler. My suggestion is: ArrayRealVector implements a sparse iterator which returns only values != 0? Having the backing storage implementation open, one could think of: * isArray * isBanded * isSymetrical * isDiagonal as additional markers or put the whole thing in an enum or EnumSet? Am Mittwoch, den 17.08.2011, 08:51 -0700 schrieb Ted Dunning: I think that all vectors and matrices should be able to answer the question about whether they are sparse and they should support sparse iterators, defaulting to the normal iterators in the general case. So yes to the first question. This allows the application programmer to be much less concerned about whether they are using a sparse or dense matrix without losing much performance, if any. The second question I think is much less clear. It might well be a good idea to keep the interface to help the compiler in cases where the programmer knows which general class of matrix they have. On Wed, Aug 17, 2011 at 8:29 AM, Arne Ploese aplo...@gmx.de wrote: Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning: Arne, Please read the thread again. I am providing an example of how I think things *should* be. OK. if I understand you right: isSparse() should be added to RealVector and the interface SparseRealVector can be dropped? The point of doing so is that things are not that way now. Telling me that they are not that way is pretty redundant. On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese aplo...@gmx.de wrote: Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for sparseIterator ? Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: Here is an example from the perspective of somebody adding a new kind of matrix. Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. The value of p should be in [0,1]. It would be very nice if the implementor of this matrix could extend an abstract matrix and over-ride get() to generate a value and set() to throw an unsupported operation exception. If p 0.1, then the matrix should be marked as sparse, else as dense. All operations against other matrices, sparse or dense should work well without any special handling by the implementor
Re: [Vote] Release Commons VFS 2.0
On 17 August 2011 19:37, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oh - and if for some non-obvious reason you want to create the distribution jars when you do the build you can run mvn -P apache-release clean install. I though commons normally use their own release profile, which is -Prelease ? On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oops. That should be mvn site:stage-deploy. Ralph On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report --- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/(revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the
Re: [Vote] Release Commons VFS 2.0
The Maven release plugin uses the apache-release profile which is set up in the apache parent pom. Ralph On Wed, Aug 17, 2011 at 11:49 AM, sebb seb...@gmail.com wrote: On 17 August 2011 19:37, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oh - and if for some non-obvious reason you want to create the distribution jars when you do the build you can run mvn -P apache-release clean install. I though commons normally use their own release profile, which is -Prelease ? On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oops. That should be mvn site:stage-deploy. Ralph On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not
Re: [Vote] Release Commons VFS 2.0
Commons parent has both a release profile and an apache-release profile. The apache-release profile is used by the release plugin as it is set up for the ASF. I'm not sure what value-add (or value loss) the release profile provides. On Wed, Aug 17, 2011 at 12:12 PM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: The Maven release plugin uses the apache-release profile which is set up in the apache parent pom. Ralph On Wed, Aug 17, 2011 at 11:49 AM, sebb seb...@gmail.com wrote: On 17 August 2011 19:37, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oh - and if for some non-obvious reason you want to create the distribution jars when you do the build you can run mvn -P apache-release clean install. I though commons normally use their own release profile, which is -Prelease ? On Wed, Aug 17, 2011 at 11:35 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Oops. That should be mvn site:stage-deploy. Ralph On Wed, Aug 17, 2011 at 11:32 AM, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as
Re: [Vote] Release Commons VFS 2.0
On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.comwrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/(revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries:
Re: [Vote] Release Commons VFS 2.0
The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source
Re: [Vote] Release Commons VFS 2.0
Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts and site look good. The only thing I am missing are md5 files. Are they required (other components used to have them)? If not, you can count my +1. Oliver Am 17.08.2011 07:44, schrieb Ralph Goers: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/ (revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-javadoc.jar commons-vfs2-examples-2.0-sources.jar.asc commons-vfs2-examples-2.0.pom commons-vfs2-examples-2.0-tests.jar commons-vfs2-examples-2.0-tests.jar.asc commons-vfs2-examples-2.0.jar.asc commons-vfs2-examples-2.0.pom.asc commons-vfs2-examples-2.0-javadoc.jar.asc commons-vfs2-examples-2.0.jar commons-vfs2-examples-2.0-sources.jar commons-vfs2-project-2.0.pom.asc commons-vfs2-project-2.0.pom commons-vfs2-sandbox-2.0.pom.asc commons-vfs2-sandbox-2.0-sources.jar.asc commons-vfs2-sandbox-2.0-test-sources.jar.asc commons-vfs2-sandbox-2.0.jar commons-vfs2-sandbox-2.0-javadoc.jar commons-vfs2-sandbox-2.0-test-sources.jar commons-vfs2-sandbox-2.0.jar.asc commons-vfs2-sandbox-2.0-sources.jar commons-vfs2-sandbox-2.0-javadoc.jar.asc commons-vfs2-sandbox-2.0-tests.jar.asc commons-vfs2-sandbox-2.0-tests.jar commons-vfs2-sandbox-2.0.pom commons-vfs2-2.0.pom.asc commons-vfs2-2.0-javadoc.jar commons-vfs2-2.0-tests.jar.asc commons-vfs2-2.0-tests.jar commons-vfs2-2.0.pom commons-vfs2-2.0.jar commons-vfs2-2.0-sources.jar.asc commons-vfs2-2.0-test-sources.jar.asc commons-vfs2-2.0.jar.asc commons-vfs2-2.0-sources.jar commons-vfs2-2.0-test-sources.jar commons-vfs2-2.0-javadoc.jar.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 8/17/11 12:45 PM, Oliver Heger wrote: Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts and site look good. The only thing I am missing are md5 files. Are they required (other components used to have them)? If not, you can count my +1. The md5s are required and we should test them as part of validating the release candidate. Phil Oliver Am 17.08.2011 07:44, schrieb Ralph Goers: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/ (revision 1158401). Site: http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-javadoc.jar commons-vfs2-examples-2.0-sources.jar.asc commons-vfs2-examples-2.0.pom commons-vfs2-examples-2.0-tests.jar commons-vfs2-examples-2.0-tests.jar.asc commons-vfs2-examples-2.0.jar.asc commons-vfs2-examples-2.0.pom.asc commons-vfs2-examples-2.0-javadoc.jar.asc commons-vfs2-examples-2.0.jar commons-vfs2-examples-2.0-sources.jar commons-vfs2-project-2.0.pom.asc commons-vfs2-project-2.0.pom commons-vfs2-sandbox-2.0.pom.asc commons-vfs2-sandbox-2.0-sources.jar.asc commons-vfs2-sandbox-2.0-test-sources.jar.asc commons-vfs2-sandbox-2.0.jar commons-vfs2-sandbox-2.0-javadoc.jar commons-vfs2-sandbox-2.0-test-sources.jar commons-vfs2-sandbox-2.0.jar.asc commons-vfs2-sandbox-2.0-sources.jar commons-vfs2-sandbox-2.0-javadoc.jar.asc commons-vfs2-sandbox-2.0-tests.jar.asc commons-vfs2-sandbox-2.0-tests.jar commons-vfs2-sandbox-2.0.pom commons-vfs2-2.0.pom.asc commons-vfs2-2.0-javadoc.jar commons-vfs2-2.0-tests.jar.asc commons-vfs2-2.0-tests.jar commons-vfs2-2.0.pom commons-vfs2-2.0.jar commons-vfs2-2.0-sources.jar.asc commons-vfs2-2.0-test-sources.jar.asc commons-vfs2-2.0.jar.asc commons-vfs2-2.0-sources.jar commons-vfs2-2.0-test-sources.jar commons-vfs2-2.0-javadoc.jar.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
Nope. That is my mistake. Maven generated them when it uploaded them to the Nexus staging repo. But I deleted that since we don't deliver them from there. I then uploaded the artifacts from where they were built on my machine to the directory on people.a.o rather than grabbing them from Nexus, which is what I should have done. I'll have to correct that. Ralph On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger oliver.he...@oliver-heger.de wrote: Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts and site look good. The only thing I am missing are md5 files. Are they required (other components used to have them)? If not, you can count my +1. Oliver Am 17.08.2011 07:44, schrieb Ralph Goers: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ (revision 1158401). Site: http://people.apache.org/~**rgoers/commons-vfs/site/http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~**rgoers/commons-vfs/staged/http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**examples/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**project/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**sandbox/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-**javadoc.jar commons-vfs2-examples-2.0-**sources.jar.asc commons-vfs2-examples-2.0.pom commons-vfs2-examples-2.0-**tests.jar commons-vfs2-examples-2.0-**tests.jar.asc commons-vfs2-examples-2.0.jar.**asc commons-vfs2-examples-2.0.pom.**asc commons-vfs2-examples-2.0-**javadoc.jar.asc commons-vfs2-examples-2.0.jar commons-vfs2-examples-2.0-**sources.jar commons-vfs2-project-2.0.pom.**asc commons-vfs2-project-2.0.pom commons-vfs2-sandbox-2.0.pom.**asc commons-vfs2-sandbox-2.0-**sources.jar.asc commons-vfs2-sandbox-2.0-test-**sources.jar.asc commons-vfs2-sandbox-2.0.jar commons-vfs2-sandbox-2.0-**javadoc.jar commons-vfs2-sandbox-2.0-test-**sources.jar commons-vfs2-sandbox-2.0.jar.**asc commons-vfs2-sandbox-2.0-**sources.jar commons-vfs2-sandbox-2.0-**javadoc.jar.asc commons-vfs2-sandbox-2.0-**tests.jar.asc commons-vfs2-sandbox-2.0-**tests.jar commons-vfs2-sandbox-2.0.pom commons-vfs2-2.0.pom.asc commons-vfs2-2.0-javadoc.jar commons-vfs2-2.0-tests.jar.asc commons-vfs2-2.0-tests.jar commons-vfs2-2.0.pom commons-vfs2-2.0.jar commons-vfs2-2.0-sources.jar.**asc commons-vfs2-2.0-test-sources.**jar.asc commons-vfs2-2.0.jar.asc commons-vfs2-2.0-sources.jar commons-vfs2-2.0-test-sources.**jar commons-vfs2-2.0-javadoc.jar.**asc --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Vote] Release Commons VFS 2.0
On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Staying on the web site is fine. Releasing code and jars that we do not intend to support is not, so I am -1 on this release. We used to have an /experimental tree in [math] that we omitted from source and binary releases. In the source assembly descriptor, this kind of thing at least used to work: fileSet directorysrc/directory excludes exclude**/mantissa/**/exclude exclude**/experimental/**/exclude /excludes /fileset Phil Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the
[lang?] Converting an array to an Iterable
Hi, recently I stumbled over the use case to obtain an Iterable for an array. I was pretty sure that there should already be a solution for this problem, but could not find anything in the JDK or in [lang]. Would this be an addition to [lang]? Maybe in ArrayUtils? Oliver - 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
OK. I will take care of this, the MD5 issue and do something with the README in a few hours after I get home from work and send out another release vote. In the meantime, if there are any other problems that should be corrected I'd appreciate the feedback. Ralph On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Staying on the web site is fine. Releasing code and jars that we do not intend to support is not, so I am -1 on this release. We used to have an /experimental tree in [math] that we omitted from source and binary releases. In the source assembly descriptor, this kind of thing at least used to work: fileSet directorysrc/directory excludes exclude**/mantissa/**/exclude exclude**/experimental/**/exclude /excludes /fileset Phil Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] ---
Re: [Vote] Release Commons VFS 2.0
Le 17/08/2011 22:13, ralph.goers @dslextreme.com a écrit : OK. I will take care of this, the MD5 issue and do something with the README in a few hours after I get home from work and send out another release vote. Was this vote offocially cancelled ? Luc In the meantime, if there are any other problems that should be corrected I'd appreciate the feedback. Ralph On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitzphil.ste...@gmail.com wrote: On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Staying on the web site is fine. Releasing code and jars that we do not intend to support is not, so I am -1 on this release. We used to have an /experimental tree in [math] that we omitted from source and binary releases. In the source assembly descriptor, this kind of thing at least used to work: fileSet directorysrc/directory excludes exclude**/mantissa/**/exclude exclude**/experimental/**/exclude /excludes /fileset Phil Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitzphil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregorygarydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 ---
Re: [lang?] Converting an array to an Iterable
What would this do that java.util.Arrays.asList does not? - Original Message -From: quot;Oliver Hegerquot; ;oliver.he...@oliver-heger.de
Re: [Vote] Release Commons VFS 2.0
Sorry, yes. Ralph On Wed, Aug 17, 2011 at 1:33 PM, Luc Maisonobe luc.maison...@free.frwrote: Le 17/08/2011 22:13, ralph.goers @dslextreme.com a écrit : OK. I will take care of this, the MD5 issue and do something with the README in a few hours after I get home from work and send out another release vote. Was this vote offocially cancelled ? Luc In the meantime, if there are any other problems that should be corrected I'd appreciate the feedback. Ralph On Wed, Aug 17, 2011 at 1:05 PM, Phil Steitzphil.ste...@gmail.com wrote: On 8/17/11 12:43 PM, ralph.goers @dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Staying on the web site is fine. Releasing code and jars that we do not intend to support is not, so I am -1 on this release. We used to have an /experimental tree in [math] that we omitted from source and binary releases. In the source assembly descriptor, this kind of thing at least used to work: fileSet directorysrc/directory excludes exclude**/mantissa/**/**exclude exclude**/experimental/**/**exclude /excludes /fileset Phil Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitzphil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregorygarydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~**rgoers/commons-vfs/staged/http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-**plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/**org/apache/commons/commons-** vfs-examples/2.0/commons-vfs-**examples-2.0.pomhttp://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.**ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-**vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-**vfs-examples:pom:2.0 at org.apache.maven.project.**DefaultProjectBuilder.build(** DefaultProjectBuilder.java:**272) at org.apache.maven.project.**DefaultMavenProjectBuilder.** buildFromRepository(**DefaultMavenProjectBuilder.**java:237) at org.apache.maven.project.**DefaultMavenProjectBuilder.**
Re: [Vote] Release Commons VFS 2.0
On 17 August 2011 20:43, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete Can't you just remove it from the modules list? That should stop Maven creating the jars at least. In fact, if we are not releasing sandbox it really ought to be disabled in the POM (perhaps via a profile) it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report --- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot. Gary On Wed, Aug 17, 2011 at 1:44 AM, Ralph Goers ralph.go...@dslextreme.com wrote: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010
Re: [Vote] Release Commons VFS 2.0
On 17 August 2011 20:55, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Nope. That is my mistake. Maven generated them when it uploaded them to the Nexus staging repo. But I deleted that since we don't deliver them from there. I then uploaded the artifacts from where they were built on my machine to the directory on people.a.o rather than grabbing them from Nexus, which is what I should have done. I'll have to correct that. Rather than copying them before the vote, you could leave the zip/tgz archives in the Nexus staging area until the vote is complete. Then, just before publishing the staging repo, copy the non-Maven files to the dist/ directory and delete from staging. Then release the staging area. Saves at least one set of copying. Ralph On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger oliver.he...@oliver-heger.de wrote: Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts and site look good. The only thing I am missing are md5 files. Are they required (other components used to have them)? If not, you can count my +1. Oliver Am 17.08.2011 07:44, schrieb Ralph Goers: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ (revision 1158401). Site: http://people.apache.org/~**rgoers/commons-vfs/site/http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~**rgoers/commons-vfs/staged/http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**examples/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**project/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**sandbox/https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-**javadoc.jar commons-vfs2-examples-2.0-**sources.jar.asc commons-vfs2-examples-2.0.pom commons-vfs2-examples-2.0-**tests.jar commons-vfs2-examples-2.0-**tests.jar.asc commons-vfs2-examples-2.0.jar.**asc commons-vfs2-examples-2.0.pom.**asc commons-vfs2-examples-2.0-**javadoc.jar.asc commons-vfs2-examples-2.0.jar commons-vfs2-examples-2.0-**sources.jar commons-vfs2-project-2.0.pom.**asc commons-vfs2-project-2.0.pom commons-vfs2-sandbox-2.0.pom.**asc commons-vfs2-sandbox-2.0-**sources.jar.asc commons-vfs2-sandbox-2.0-test-**sources.jar.asc commons-vfs2-sandbox-2.0.jar commons-vfs2-sandbox-2.0-**javadoc.jar commons-vfs2-sandbox-2.0-test-**sources.jar commons-vfs2-sandbox-2.0.jar.**asc commons-vfs2-sandbox-2.0-**sources.jar commons-vfs2-sandbox-2.0-**javadoc.jar.asc commons-vfs2-sandbox-2.0-**tests.jar.asc commons-vfs2-sandbox-2.0-**tests.jar commons-vfs2-sandbox-2.0.pom commons-vfs2-2.0.pom.asc commons-vfs2-2.0-javadoc.jar commons-vfs2-2.0-tests.jar.asc commons-vfs2-2.0-tests.jar commons-vfs2-2.0.pom commons-vfs2-2.0.jar commons-vfs2-2.0-sources.jar.**asc commons-vfs2-2.0-test-sources.**jar.asc commons-vfs2-2.0.jar.asc commons-vfs2-2.0-sources.jar
[Math] New method: addToEntry in RealVector
Hi. 1. Is it OK to add an addToEntry method to RealVector? [There is one in AbstractRealMatrix.] Do I need to open a JIRA issue for this? 2. Are we going to remove the RealVector interface in favour of keeping only an abstract concrete class (AbstractRealVector) at the top of the hierarchy? [The class could be renamed RealVector.] 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
I didn't check, but for some reason I assumed that once I do a close that I wouldn't be able to delete anything. But you are correct. I can do that so I will as it is easier. Ralph On Wed, Aug 17, 2011 at 2:51 PM, sebb seb...@gmail.com wrote: On 17 August 2011 20:55, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: Nope. That is my mistake. Maven generated them when it uploaded them to the Nexus staging repo. But I deleted that since we don't deliver them from there. I then uploaded the artifacts from where they were built on my machine to the directory on people.a.o rather than grabbing them from Nexus, which is what I should have done. I'll have to correct that. Rather than copying them before the vote, you could leave the zip/tgz archives in the Nexus staging area until the vote is complete. Then, just before publishing the staging repo, copy the non-Maven files to the dist/ directory and delete from staging. Then release the staging area. Saves at least one set of copying. Ralph On Wed, Aug 17, 2011 at 12:45 PM, Oliver Heger oliver.he...@oliver-heger.de wrote: Build is now successful under Windows 7 with Java 1.5 and 1.6. Artifacts and site look good. The only thing I am missing are md5 files. Are they required (other components used to have them)? If not, you can count my +1. Oliver Am 17.08.2011 07:44, schrieb Ralph Goers: This is a vote to release Apache Commons VFS 2.0. Changes made since the last candidate: * Fixed the manifest error that was causing the build to fail. * Changed the copyright date in the Notice file from 2010 to 2011. * Removed the references to javamail from the Notice file. * Removed all the @version tags * Fixed the EOL issues with README.txt, RELEASE-NOTES.txt, and src/changes/announcement.vm (osgi/MANIFEST.MF has been removed). * Modified the release notes to mention the code is not source compatible with VFS 1.x and that the package name changed. * Fixed the WARNING for the use of the deprecated tasks element. * Fixed the WARNING for the use of the deprecated systemProperties element. * Made sure all jars have NOTICE.txt and LICENSE.txt The build message [WARNING] Ignoring project type pom - supportedProjectTypes = [jar, bundle] was not fixed as that is due to commons parent causing the maven-bundle plugin to run on all subprojects, including those that don't generate bundles or jars. I have also removed files that shouldn't be present in the Maven repository from the staging repo. [ ] +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-vfs2-project-2.0/ https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs2-project-2.0/ (revision 1158401). Site: http://people.apache.org/~**rgoers/commons-vfs/site/ http://people.apache.org/~rgoers/commons-vfs/site/ Binaries: http://people.apache.org/~**rgoers/commons-vfs/staged/ http://people.apache.org/~rgoers/commons-vfs/staged/ The following artifacts have been staged to the org.apache.commons-045 (u:rgoers, a:208.29.163.248) repository. The Maven artifacts are at: https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**examples/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-examples/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**project/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-project/ https://repository.apache.org/**content/groups/staging/org/** apache/commons/commons-vfs2-**sandbox/ https://repository.apache.org/content/groups/staging/org/apache/commons/commons-vfs2-sandbox/ and consist of archetype-catalog.xml commons-vfs2-examples-2.0-**javadoc.jar commons-vfs2-examples-2.0-**sources.jar.asc commons-vfs2-examples-2.0.pom commons-vfs2-examples-2.0-**tests.jar commons-vfs2-examples-2.0-**tests.jar.asc commons-vfs2-examples-2.0.jar.**asc commons-vfs2-examples-2.0.pom.**asc commons-vfs2-examples-2.0-**javadoc.jar.asc commons-vfs2-examples-2.0.jar commons-vfs2-examples-2.0-**sources.jar commons-vfs2-project-2.0.pom.**asc commons-vfs2-project-2.0.pom commons-vfs2-sandbox-2.0.pom.**asc commons-vfs2-sandbox-2.0-**sources.jar.asc commons-vfs2-sandbox-2.0-test-**sources.jar.asc commons-vfs2-sandbox-2.0.jar commons-vfs2-sandbox-2.0-**javadoc.jar commons-vfs2-sandbox-2.0-test-**sources.jar commons-vfs2-sandbox-2.0.jar.**asc commons-vfs2-sandbox-2.0-**sources.jar commons-vfs2-sandbox-2.0-**javadoc.jar.asc
Re: [Vote] Release Commons VFS 2.0
I'd prefer to not remove it from the modules list as that will also remove it from the web site. Ralph On Wed, Aug 17, 2011 at 2:46 PM, sebb seb...@gmail.com wrote: On 17 August 2011 20:43, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete Can't you just remove it from the modules list? That should stop Maven creating the jars at least. In fact, if we are not releasing sandbox it really ought to be disabled in the POM (perhaps via a profile) it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report--- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do not know if I should -1 this because there are no build instructions, or if there are, they are located in some non-obvious spot.
Re: [Vote] Release Commons VFS 2.0
On 17 August 2011 23:17, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: I'd prefer to not remove it from the modules list as that will also remove it from the web site. But then surely source archive builds will fail? Ralph On Wed, Aug 17, 2011 at 2:46 PM, sebb seb...@gmail.com wrote: On 17 August 2011 20:43, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: The sandbox question I can't answer very well. The sandbox stuff was there long before I arrived to work on VFS, although I rewrote the webdav stuff and moved it to core. The only real description is on the web site under File Systems where it says they under in development (not by me :-) ). None of the sandbox stuff appears to have been distributed with the 1.0 release, including in the source distribution. I don't know of a way I can stop Maven from deploying it to the staging repo, but I can certainly delete Can't you just remove it from the modules list? That should stop Maven creating the jars at least. In fact, if we are not releasing sandbox it really ought to be disabled in the POM (perhaps via a profile) it from there just like I did the distribution zips. If desired, I'd have to do another release to remove that source from the release. It would also stay on the web site. Ralph On Wed, Aug 17, 2011 at 12:27 PM, Phil Steitz phil.ste...@gmail.com wrote: On 8/17/11 11:32 AM, ralph.goers @dslextreme.com wrote: What do you mean It did not work? This is a multi-project site so in general mvn site is useless. You have to run mvn site:stage-deply -DstagingSiteURL=file url where I want the site to go. I suppose I could add that to the readme, but it is documented pretty well on the maven site plugin web site. In a prior release candidate I wasn't generating the release notes and I had the comment in the README. The release was vetoed due to the lack of release notes. I simply forgot to delete the README. Did you run announcement-generate from the core directory? That only works at the project root. The build instructions consist of: mvn clean install Those instructions appear on the Download and Build paged linked in the main site menu, so I don't see this as a a blocker. Instructions on how to build the site are nice to have, but not showstoppers, IMO - especially since they generally stop working as incompatible plugin and / or maven versions change. One question I have and I apologize if this has already been discussed is are we sure we want to release the sandbox stuff? There is no disclaimer of any kind on the web site or in the release notes. If the contents of that jar are being released as normal artifacts, why is it called sandbox? If not, why no explanation anywhere of what sandbox means? Phil Ralph On Wed, Aug 17, 2011 at 8:13 AM, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I am not sure if I am building correctly, but here is what I found. Some build instructions in the readme.txt file would help. Downloaded source zip from http://people.apache.org/~rgoers/commons-vfs/staged/ From the root I ran mvn site which did not work. Fine, starting to poke around. From the dist directory I ran mvn site which did not work: [INFO] Generating Dependency Management report --- maven-project-info-reports-plugin:2.3.1 Downloading: http://repo1.maven.org/maven2/org/apache/commons/commons-vfs-examples/2.0/commons-vfs-examples-2.0.pom [WARNING] Unable to create Maven project from repository. org.apache.maven.project.ProjectBuildingException: Error resolving project artifact: Failure to find org.apache.commons:commons-vfs-examples:pom:2.0 in http://r epo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are for ced for project org.apache.commons:commons-vfs-examples:pom:2.0 at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:272) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:237) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:252) Why would building the site require an installed VFS2? The README.txt says to run mvn changes:announcement-generate to get release notes but there is a RELEASE-NOTES.txt file in the same dir. Why do we need two? When I do run mvn changes:announcement-generate, I get: [INFO] --- maven-changes-plugin:2.4:announcement-generate (default-cli) @ commons-vfs2 --- [WARNING] changes.xml file C:\test\commons-vfs-2.0\core\src\changes\changes.xml does not exist. There is no such file. I do
Re: [Math] New method: addToEntry in RealVector
On 8/17/11 3:14 PM, Gilles Sadowski wrote: Hi. 1. Is it OK to add an addToEntry method to RealVector? [There is one in AbstractRealMatrix.] Do I need to open a JIRA issue for this? 2. Are we going to remove the RealVector interface in favour of keeping only an abstract concrete class (AbstractRealVector) at the top of the hierarchy? [The class could be renamed RealVector.] +1 to go ahead and remove the interface and reclaim the name. This is a little scary, but now is the time to do these things. I am thinking about doing the same thing in lots of interface/impl splits where we have only one impl. If anyone is opposed to this, please speak up now. I think each such change should be tracked in a JIRA and changes.xml so we have a record of the decision and the associated commits. Phil 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: [Math] iterator and sparseIterator in RealVector hierarchy
On symmetrics, diagonal, banded and so on, I disagree-as I have made clear in the past. In the case of White standard errors or panel regressions, you typically have long strings of multiplication by diagonals and symmetrics, sandwich products and so forth. There are enough of these types of operations that a math/stat library should support these forms of matrices. isSparse() will not cut it. A symmetric matrix is typically NOT sparse, it is typically dense in these cases. More importantly, the number of operations you save by explicitly recognizing the special structure is not insignificant. For banded arrays, the economies available beyond simple sparse algorithms are even more limited. I am confused, Ted, since when I suggested that some of the multiplication issues could solved by method overloading, you thought it would not work. Probably a mis-communication on my part. Symmetric and triangular matrices also have special properties but it is hard to decide what is really important there. Many of the special operations for these kinds of matrix are subject to solving by overloads instead of indicators since we aren't dealing with binary operations. For example, left and right inverse multiplication with triangular matrices is handled by normal single dispatch and qualifying an argument for real Cholesky decomposition is specific to the Cholesky decomposition itself. While on the discussion of extending RealMatrix in any direction, I would humbly offer that the objects are too complex. Pardon this foolish question, but what are the uses for the methods double walkInRowOrder(RealMatrixChangingVisitor visitor) When I think of having to fill in all those methods for any extension, my head spins. -Greg
Re: [Math] iterator and sparseIterator in RealVector hierarchy
On Wed, Aug 17, 2011 at 4:24 PM, Greg Sterijevski gsterijev...@gmail.comwrote: On symmetrics, diagonal, banded and so on, I disagree-as I have made clear in the past. In the case of White standard errors or panel regressions, you typically have long strings of multiplication by diagonals and symmetrics, sandwich products and so forth. There are enough of these types of operations that a math/stat library should support these forms of matrices. isSparse() will not cut it. A symmetric matrix is typically NOT sparse, it is typically dense in these cases. More importantly, the number of operations you save by explicitly recognizing the special structure is not insignificant. I agree pretty much for the symmetric case. The savings for banded matrices is surprisingly small and you can have all of those savings as a left operand. It is the right operand where simple sparsity accounts for almost everything. For banded arrays, the economies available beyond simple sparse algorithms are even more limited. I am confused, Ted, since when I suggested that some of the multiplication issues could solved by method overloading, you thought it would not work. Probably a mis-communication on my part. No. What I mean is that when a sparse matrix is the right operand and not subject overloading due to dynamic typing, you get most of the advantages of the fancy optimizations without any need for anything more than isSparse and a sparse iterator. You don't get all of the benefit, but you do get most of it and you get it for a wide variety of left operands. Symmetric and triangular matrices also have special properties but it is hard to decide what is really important there. Many of the special operations for these kinds of matrix are subject to solving by overloads instead of indicators since we aren't dealing with binary operations. For example, left and right inverse multiplication with triangular matrices is handled by normal single dispatch and qualifying an argument for real Cholesky decomposition is specific to the Cholesky decomposition itself. While on the discussion of extending RealMatrix in any direction, I would humbly offer that the objects are too complex. Pardon this foolish question, but what are the uses for the methods double walkInRowOrder(RealMatrixChangingVisitor visitor) When I think of having to fill in all those methods for any extension, my head spins. Exactly. I think that you shouldn't need that. The abstract super class should have a moderately fancy operation that is limited to handling generically sparse and dense matrices reasonably well and dense x dense cases really well. The writer of a new matrix type should not need to know about that at all. What I was suggesting is that if you have a leftInverseMultiply method that solves for x in the system Ax = b, then that method knows the type of A because the natural method call is A.leftInverseMultiply(b). Thus, if A has special structure, you get what you need from normal method dispatch. It is the cases like A.times(b) or A.plus(b) that will be best supported by generic sparsity support in the abstract class.
Re: [Math] New method: addToEntry in RealVector
Are you going to add addAndScale and all the other gazillion common mutators as well? Or should there just be a functional style interface where you say A.assign(Functions.plus(3.0)) to add 3 to all elements of a matrix or vector? That would then allow A.assign(Functions.ABS) or A.assign(Functions.times(0.3)) This allows one method to serve many, many purposes, including those that are not yet known. Similar logic leads to a family of assign methods and also some aggregate methods. The resulting flexibility and parsimony is very nice. On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: 1. Is it OK to add an addToEntry method to RealVector? [There is one in
Re: [Vote] Release Commons VFS 2.0
On Aug 17, 2011, at 3:27 PM, sebb wrote: On 17 August 2011 23:17, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: I'd prefer to not remove it from the modules list as that will also remove it from the web site. But then surely source archive builds will fail? Yeah. I'll have to think about that. I hate it when you make me think. So somehow the site build should include the module and the rest of the time it is not enabled. 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 18 August 2011 01:09, Ralph Goers ralph.go...@dslextreme.com wrote: On Aug 17, 2011, at 3:27 PM, sebb wrote: On 17 August 2011 23:17, ralph.goers @dslextreme.com ralph.go...@dslextreme.com wrote: I'd prefer to not remove it from the modules list as that will also remove it from the web site. But then surely source archive builds will fail? Yeah. I'll have to think about that. I hate it when you make me think. So somehow the site build should include the module and the rest of the time it is not enabled. Try using a profile to enable it, and ensure you enable the profile when building the site, but not when building the artifacts. 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: [math] StorelessCovariance
I am building in Netbeans and I believe that Luc is correct. I initially had problems until I included the junit.jar. (junit-4.8.2.jar) PS What is your approach to the covariance matrix? Are you building a sum of squares matrix or keeping updates of the mean, ... etc? On Wed, Aug 17, 2011 at 1:22 PM, Luc Maisonobe luc.maison...@free.frwrote: Hi Patrick, Le 17/08/2011 18:15, Patrick Meyer a écrit : I am workin on the StorelessCovariance per jira MATH-449. However, I'm having a hard time using subversion via Netbeans. I have successfully created the new classes and a JUnit test. However, when I run the test I get the following message, caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/**TestUtils Do you have a complete implementation of JUnit in your classpath or only the top level API ? It seems similar to this: http://www.andrejkoelewijn.** com/wp/2010/03/04/absent-code-**attribute-in-method-that-is-** not-native-or-abstract/http://www.andrejkoelewijn.com/wp/2010/03/04/absent-code-attribute-in-method-that-is-not-native-or-abstract/ or this http://dominikdorn.com/2010/**05/maven-junit-** classformaterror-absent-code-**attribute/http://dominikdorn.com/2010/05/maven-junit-classformaterror-absent-code-attribute/ and hence elated to API and implementation separation. Apache Commons Math does not have any runtime dependency and the only test time dependency is JUnit. Luc Any help would be appreciated. I have a lot to contribute to commons math but my lack of experience with subversion is really hindering me. Thanks, Patrick --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] New method: addToEntry in RealVector
Shocking as this may seem! ;-) I like Ted's suggestion. Very clean, an appropriate use of OO and something for which the penalty is not great, but the benefit humongous! +1 for functional/functor approach. On Wed, Aug 17, 2011 at 6:44 PM, Ted Dunning ted.dunn...@gmail.com wrote: Are you going to add addAndScale and all the other gazillion common mutators as well? Or should there just be a functional style interface where you say A.assign(Functions.plus(3.0)) to add 3 to all elements of a matrix or vector? That would then allow A.assign(Functions.ABS) or A.assign(Functions.times(0.3)) This allows one method to serve many, many purposes, including those that are not yet known. Similar logic leads to a family of assign methods and also some aggregate methods. The resulting flexibility and parsimony is very nice. On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: 1. Is it OK to add an addToEntry method to RealVector? [There is one in
Re: [math] StorelessCovariance
OK, after fidgeting with NetBeans for too long without results, I went with Phil's suggestion and just used subversion at the command prompt. It was much easier than trying to configure NetBeans. I uploaded the patch this evening. It includes two new classes StorelessCovariance.java and StorelessCovarianceMatrix.java. I also included a new test class StorelessCovarianceTest.java. Interestingly, the one-pass algorithm is slightly less accurate than the two-pass algorithm. I had to reduce the tolerance from 10E-9 to 10E-7 in order for tests to pass with the Longley data. The tolerance was not changed for the Swiss data. It remained 10E-13 for the Swiss data. The one-pass algorithm is described in a paper by Pebay (2008) http://prod.sandia.gov/techlib/access-control.cgi/2008/086212.pdf Thanks for everyone's help. Patrick On 8/17/2011 12:13 PM, Patrick wrote: I am workin on the StorelessCovariance per jira MATH-449. However, I'm having a hard time using subversion via Netbeans. I have successfully created the new classes and a JUnit test. However, when I run the test I get the following message, caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/TestUtils Any help would be appreciated. I have a lot to contribute to commons math but my lack of experience with subversion is really hindering me. Thanks, Patrick - 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] StorelessCovariance
NetBeans is kind of wasting away for lack of attention. IntelliJ generally gets these things exactly correct. SVN, git and mvn are all mother tongues for it. There is an excellent community edition and Apache committers can get a full version. On Wed, Aug 17, 2011 at 8:09 PM, Patrick Meyer meyer...@gmail.com wrote: OK, after fidgeting with NetBeans for too long without results, I went with Phil's suggestion and just used subversion at the command prompt. It was much easier than trying to configure NetBeans. I uploaded the patch this evening. It includes two new classes StorelessCovariance.java and StorelessCovarianceMatrix.**java. I also included a new test class StorelessCovarianceTest.java. Interestingly, the one-pass algorithm is slightly less accurate than the two-pass algorithm. I had to reduce the tolerance from 10E-9 to 10E-7 in order for tests to pass with the Longley data. The tolerance was not changed for the Swiss data. It remained 10E-13 for the Swiss data. The one-pass algorithm is described in a paper by Pebay (2008) http://prod.sandia.gov/**techlib/access-control.cgi/**2008/086212.pdfhttp://prod.sandia.gov/techlib/access-control.cgi/2008/086212.pdf Thanks for everyone's help. Patrick On 8/17/2011 12:13 PM, Patrick wrote: I am workin on the StorelessCovariance per jira MATH-449. However, I'm having a hard time using subversion via Netbeans. I have successfully created the new classes and a JUnit test. However, when I run the test I get the following message, caused an ERORR: Absent Code attribute in method that is not native or abstract in class file org/apache/commons/math/**TestUtils Any help would be appreciated. I have a lot to contribute to commons math but my lack of experience with subversion is really hindering me. Thanks, Patrick --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.orgdev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] New method: addToEntry in RealVector
Credit where it is due: this style of API was a major characteristic of Colt and Mahout inherited this style (to our benefit). On Wed, Aug 17, 2011 at 6:41 PM, Greg Sterijevski gsterijev...@gmail.comwrote: Shocking as this may seem! ;-) I like Ted's suggestion. Very clean, an appropriate use of OO and something for which the penalty is not great, but the benefit humongous! +1 for functional/functor approach. On Wed, Aug 17, 2011 at 6:44 PM, Ted Dunning ted.dunn...@gmail.com wrote: Are you going to add addAndScale and all the other gazillion common mutators as well? Or should there just be a functional style interface where you say A.assign(Functions.plus(3.0)) to add 3 to all elements of a matrix or vector? That would then allow A.assign(Functions.ABS) or A.assign(Functions.times(0.3)) This allows one method to serve many, many purposes, including those that are not yet known. Similar logic leads to a family of assign methods and also some aggregate methods. The resulting flexibility and parsimony is very nice. On Wed, Aug 17, 2011 at 3:14 PM, Gilles Sadowski gil...@harfang.homelinux.org wrote: 1. Is it OK to add an addToEntry method to RealVector? [There is one in