Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support
Tell me why 1.6 is a problem again? This is DB-helper code, so much less worried about use cases like Android. Hen On Fri, Jan 6, 2012 at 3:05 AM, sebb seb...@gmail.com wrote: I did some experimenting with BeanProcessor to see what would be involved in providing Java 1.5 support. As part of this, I tried commenting out the new code that requires Java 1.6. All tests still worked. I then commented out most of the rest of the else if clauses in the processColumn method, and the unit tests still worked. I think it might be fairly easy to recode the SQLXML section so it still works in Java 1.5, but without a proper unit test, this is difficult to prove. In any case, more unit tests are definitely needed. - 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] Compatibility of licenses?
Hi Henri Hi, about this Python code you wrote 14 years ago :) :)) Highly unlikely he's jumping at the bit to code in Commons Math. Still, sending a thanks is polite and I'd recommend you doing it as it always sounds best coming from the person closest to the commit. That's how I felt about it, but I certainly do not want to act above my rank. Thanks for this advice, I'll remember about it next time I come across this issue. Sébastien Hen - 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: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
On Tue, Jan 10, 2012 at 10:19 AM, sebb seb...@gmail.com wrote: On 10 January 2012 16:45, Siegfried Goeschl sgoes...@gmx.at wrote: Hi folks, the main reason for the failed vote of commons-email-1.3 is that the release is only source but not binary compatible +) if you compile your application with the new version everything is fine +) if you replace simply the JAR the invocation fails Is it mandatory that a minor release is binary compatible with the previous one or do I have to create a new major version? There is a lot of ugly stuff (mainly protected member variables) which should be done but is currently not in the scope of this release. If the jar is not a drop-in replacement for the previous version, then yes, IMO that requires a major release. [1] The only possible exception might be if the incompatibilities are in internal parts of the API, i.e. classes/methods etc. that are not used externally. Thinking back on previous discussions, the primary exception has been the API itself is the bug and needs changing. A contrived (and over-simple) example would be: public void toUppercase(String s); It'd be better to fix the return type than live with bad API. Rare, but worth mentioning I thought. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Supported Buildsystems of each component
Couldn't we generate this? It feels like a very simple svn script to see if a component has a build.xml, pom.xml or project.xml. Hen On Sun, Jan 8, 2012 at 4:50 AM, Christian Grobmeier grobme...@gmail.com wrote: Hello, we have a nice wikipage mentioning what buildsystem is supported for which component: http://wiki.apache.org/commons/BuildSystems Can everybody update the lines for the components he is caring about? For components which do not support maven3 just add a no in the column - this way we know which lines have been updated. Cheers, Christian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230419 - in /commons/proper/math/trunk/src: main/java/org/apache/commons/math/distribution/TriangularDistribution.java test/java/org/apache/commons/math/distribution/TriangularDistri
Hi Luc You should probably also change the NOTICE file to include the licence text from the original code. Luc In fact, this piece of code turned out to be very standard (and corresponded exactly to the default implementation of the base class, see my comments on MATH-731). So no need to refer to the guy who initially inspired Dennis. So this time, I won't use the advice I've received from legal-discuss, but I shall try to remember it!!! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230435 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java
Hello. On Thu, Jan 12, 2012 at 08:08:29AM -, celes...@apache.org wrote: Author: celestin Date: Thu Jan 12 08:08:29 2012 New Revision: 1230435 URL: http://svn.apache.org/viewvc?rev=1230435view=rev Log: Removed invocations of some Java 1.6 methods (MATH-731). Modified: commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java Modified: commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java URL: http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java?rev=1230435r1=1230434r2=1230435view=diff == --- commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java (original) +++ commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java Thu Jan 12 08:08:29 2012 @@ -100,7 +100,10 @@ public class TriangularDistributionTest // probability of zero and one, meaning the inverse returns the // limits and not the points outside the limits. double[] points = makeCumulativeTestValues(); -return Arrays.copyOfRange(points, 1, points.length - 1); +double[] points2 = new double[points.length-2]; +System.arraycopy(points, 1, points2, 0, points2.length); +return points2; +//return Arrays.copyOfRange(points, 1, points.length - 1); } You might want to create a copyOfRange method in class o.a.c.m.util.MathArrays. [This will remind that some code could be upgraded when the target version allows it.] Regards, Gilles /** @@ -113,7 +116,10 @@ public class TriangularDistributionTest // probability of zero and one, meaning the inverse returns the // limits and not the points outside the limits. double[] points = makeCumulativeTestPoints(); -return Arrays.copyOfRange(points, 1, points.length - 1); +double[] points2 = new double[points.length-2]; +System.arraycopy(points, 1, points2, 0, points2.length); +return points2; +//return Arrays.copyOfRange(points, 1, points.length - 1); } /** Creates the default probability density test expected values. */ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
2012/1/12 Sébastien Brisard sebastien.bris...@m4x.org: Hi Dennis, 2012/1/12 Dennis Hendriks d.hendr...@tue.nl: The online report at the top links to a page with details. right under my nose... Sorry for bothering you with futilities. The tests use a method only available in Java 6... Right. But why neither eclipse (configured to build with Java 1.5), Did you also configure the JVM library? nor mvn complains? Maven uses the current version of Java unless you use one of the java-1.x profiles set up for the purpose. The compiler source and target settings only affect the syntax and generate byte-code. They do not affect the library jars. Sébastien Dennis Sébastien Brisard wrote: 2012/1/12 Continuum@vmbuild contin...@apache.org: Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=17130projectId=97 Build statistics: State: Failed Previous State: Ok Started at: Thu 12 Jan 2012 07:21:05 + Finished at: Thu 12 Jan 2012 07:22:12 + Total time: 1m 7s Build Trigger: Schedule Build Number: 634 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_30 Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.32-31-server arch: amd64 Family: unix SCM Changes: Changed: celestin @ Thu 12 Jan 2012 07:01:43 + Comment: Implementation of continuous triangular distributions (MATH-731). Patch contributed by Dennis Hendriks. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TriangularDistribution.java ( 1230419 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math/distribution/TriangularDistributionTest.java ( 1230419 ) 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 Hi, where can I find a detailed report on this build failure? It seems Commons-Math builds successfully locally. Thanks! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)
2012/1/12 sebb seb...@gmail.com: 2012/1/12 Sébastien Brisard sebastien.bris...@m4x.org: Hi Dennis, 2012/1/12 Dennis Hendriks d.hendr...@tue.nl: The online report at the top links to a page with details. right under my nose... Sorry for bothering you with futilities. The tests use a method only available in Java 6... Right. But why neither eclipse (configured to build with Java 1.5), Did you also configure the JVM library? No, I probably didn't. nor mvn complains? Maven uses the current version of Java unless you use one of the java-1.x profiles set up for the purpose. The compiler source and target settings only affect the syntax and generate byte-code. They do not affect the library jars. I understand: that's why @Override on an interface method are rejected, which gave me a false sense of security. Thanks for that, I'll look into how to configure the libraries as well! Sébastien Sébastien Dennis - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support
On 12 January 2012 08:20, Henri Yandell flame...@gmail.com wrote: Tell me why 1.6 is a problem again? Because there are likely to be many companies still using Java 1.5 out there. I was hoping to fix the code so they are not prevented from using the new version. This is DB-helper code, so much less worried about use cases like Android. Hen On Fri, Jan 6, 2012 at 3:05 AM, sebb seb...@gmail.com wrote: I did some experimenting with BeanProcessor to see what would be involved in providing Java 1.5 support. As part of this, I tried commenting out the new code that requires Java 1.6. All tests still worked. I then commented out most of the rest of the else if clauses in the processColumn method, and the unit tests still worked. I think it might be fairly easy to recode the SQLXML section so it still works in Java 1.5, but without a proper unit test, this is difficult to prove. In any case, more unit tests are definitely needed. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
On 01/11/2012 08:21 PM, Sébastien Brisard wrote: Hi, Hi Sébastien, My problem is: how to do that? 1. Extend RealLinearOperator? That would allow for compile time checks. The problem is I've already defined InvertibleRealLinearOperator. So how about operators which are both invertible and transposable? 2. Create an interface, say Transposable? But then, no compile time check can be performed in LSQR.RealVector solve(RealLinearOperator a, RealVector b) (defined in AbstractIterativeLinearSolver). The only thing I can do is test whether the specified operator implements the interface Transposable. 3. Add the method operateTranspose to RealLinearOperator, and allow for UnsupportedOperationException. I could then add a method boolean isTransposable() to RealLinearOperator. Again, no compile-time check is possible. Do you have any thoughts? looking at the rationale behind RealLinearOperator I understand this class is used to calculate either: y = A x y = A^T x The specialized class InvertibleRealLinearOperator further allows for the calculation of: y = A^-1 x @Alt1: you ask about operators which are both invertible and transposable, but the two properties do not collide imho, at least as long as you do not want to calculate something like y = A^T^-1 x And in that case, wouldn't it be better to create a RealLinearOperator object with A^T as parameter? @Alt2: if the solve method relies on an operator to provide operateTranspose than it should be checked on compile time imho. Assuming that any matrix A should be transposable, I would opt for alternative 3 and provide the operateTranspose method. Do you have a case where an operator would not be transposable? Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] On graph weight type(s)
Hi all, the generic implementation of weights is finally completed, at least for currently implemented algorithms requiring weights. Check out the latest version of [graph] for details, and the related issue for description of changes: https://issues.apache.org/jira/browse/SANDBOX-356 Maybe one last effort can be made to come up with more understandable names (e.g. for a user that does not know what a Semigroup or Monoid is). Suggestions are welcome. Thank you, Claudio On 08/01/2012 18:43, Simone Tripodi wrote: Hola Claudio, I just saw the issue - flawless report! - just give me the time to process it and I'll let you know! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Jan 8, 2012 at 6:38 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: Hi, On 26/12/2011 22:09, Simone Tripodi wrote: Hi Claudio! just make your proposal and attach it to a jira Issue :) it took a while (you know, Xmas and stuff) but here it is, with description: https://issues.apache.org/jira/browse/SANDBOX-356 I hope it looks good -- quite a big patch, so of course all comments are welcome. Ciao, Claudio Hope to hear from you soon, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - 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 -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
Hi Thomas, and thanks for digging into that! looking at the rationale behind RealLinearOperator I understand this class is used to calculate either: y = A x y = A^T x Not exactly. For the time being, RealLinearOperator only provides the method RealVector operate(RealVector), which performs y = A.x. I agree with you that any linear operator is transposable (don't even know whether this word makes sense in english). However, RealLinearOperator have been implemented for operators which are *not* known in closed-form. In other words, I do not know how to access efficiently the (i, j) coefficient, but I *do* know how to compute efficiently A.x. There might be some cases where computing A'.x would still be difficult. I do not have an example here, but that's the reason why initially RealVector operateTranspose(RealVector) was not put in the RealLinearOperator abstract class. The specialized class InvertibleRealLinearOperator further allows for the calculation of: y = A^-1 x right. @Alt1: you ask about operators which are both invertible and transposable, but the two properties do not collide imho, at least as long as you do not want to calculate something like y = A^T^-1 x That's true. So are you suggesting I should write three specialized classes InvertibleRealLinearOperator, TransposableRealLinearOperator, InvertibleAndTransposableRealLinearOperator? And in that case, wouldn't it be better to create a RealLinearOperator object with A^T as parameter? Not sure I really follow, but I already thought of passing *two* RealLinearOperators to the LSQR solver, which requires A and A^T. However, LSQR would be out of the IterativeLinearSolver hierarchy in that case, since the typical signature in this hierarchy is RealVector solve(RealLinearOperator, RealVector), and LSQR would require RealVector solve(RealLinearOperator, RealLinearOperator, RealVector) @Alt2: if the solve method relies on an operator to provide operateTranspose than it should be checked on compile time imho. Agreed. I do not like the tagging interface option. Assuming that any matrix A should be transposable, I would opt for alternative 3 and provide the operateTranspose method. Do you have a case where an operator would not be transposable? Thomas I've actually started playing around with this option. Added RealVector operateTranspose(RealVector) to the RealLinearOperator abstract class. This method would be defined as optional in the Javadoc, with the option to throw an UnsupportedOperationException. I also thought about boolean isTransposable() to check at execution time that operateTranspose() has indeed been implemented. Not sure this method is absolutely necessary, though. Would be glad to read your thoughts! Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
One such example is a text retrieval engine. A x is easy since that is what the engine does. A' y is very expensive. 2012/1/12 Sébastien Brisard sebastien.bris...@m4x.org In other words, I do not know how to access efficiently the (i, j) coefficient, but I *do* know how to compute efficiently A.x. There might be some cases where computing A'.x would still be difficult. I do not have an example here, but that's the reason why initially RealVector operateTranspose(RealVector) was not put in the RealLinearOperator abstract class.
Re: [math] Transposable linear operators
2012/1/12 Ted Dunning ted.dunn...@gmail.com: One such example is a text retrieval engine. A x is easy since that is what the engine does. A' y is very expensive. 2012/1/12 Sébastien Brisard sebastien.bris...@m4x.org In other words, I do not know how to access efficiently the (i, j) coefficient, but I *do* know how to compute efficiently A.x. There might be some cases where computing A'.x would still be difficult. I do not have an example here, but that's the reason why initially RealVector operateTranspose(RealVector) was not put in the RealLinearOperator abstract class. Thanks for this example! So you *do* agree that implementing operateTranspose() should be optional, don't you? Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230600 - /commons/sandbox/graph/trunk/
welcome in the grapher brotherhood! :) http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 12, 2012 at 4:42 PM, ggreg...@apache.org wrote: Author: ggregory Date: Thu Jan 12 15:42:11 2012 New Revision: 1230600 URL: http://svn.apache.org/viewvc?rev=1230600view=rev Log: Add Eclipse files to svn:ignore. Modified: commons/sandbox/graph/trunk/ (props changed) Propchange: commons/sandbox/graph/trunk/ -- --- svn:ignore (original) +++ svn:ignore Thu Jan 12 15:42:11 2012 @@ -5,5 +5,7 @@ velocity.log* .classpath .project maven.log - InvertedEdgeAdapter.patch +maven-eclipse.xml +.externalToolBuilders +.settings - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1230600 - /commons/sandbox/graph/trunk/
:) Gary On Jan 12, 2012, at 11:50, Simone Tripodi simonetrip...@apache.org wrote: welcome in the grapher brotherhood! :) http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 12, 2012 at 4:42 PM, ggreg...@apache.org wrote: Author: ggregory Date: Thu Jan 12 15:42:11 2012 New Revision: 1230600 URL: http://svn.apache.org/viewvc?rev=1230600view=rev Log: Add Eclipse files to svn:ignore. Modified: commons/sandbox/graph/trunk/ (props changed) Propchange: commons/sandbox/graph/trunk/ -- --- svn:ignore (original) +++ svn:ignore Thu Jan 12 15:42:11 2012 @@ -5,5 +5,7 @@ velocity.log* .classpath .project maven.log - InvertedEdgeAdapter.patch +maven-eclipse.xml +.externalToolBuilders +.settings - 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] Transposable linear operators
On 01/12/2012 12:28 PM, Sébastien Brisard wrote: Hi Thomas, [snip] I agree with you that any linear operator is transposable (don't even know whether this word makes sense in english). However, RealLinearOperator have been implemented for operators which are *not* known in closed-form. In other words, I do not know how to access efficiently the (i, j) coefficient, but I *do* know how to compute efficiently A.x. There might be some cases where computing A'.x would still be difficult. I do not have an example here, but that's the reason why initially RealVector operateTranspose(RealVector) was not put in the RealLinearOperator abstract class. ok, now I understand the purpose of the operator much better. @Alt1: you ask about operators which are both invertible and transposable, but the two properties do not collide imho, at least as long as you do not want to calculate something like y = A^T^-1 x That's true. So are you suggesting I should write three specialized classes InvertibleRealLinearOperator, TransposableRealLinearOperator, InvertibleAndTransposableRealLinearOperator? not really, I think such a structuring would create more confusion and problems in the long run than make up for the subtle differences that it may model right now. And in that case, wouldn't it be better to create a RealLinearOperator object with A^T as parameter? Not sure I really follow, but I already thought of passing *two* RealLinearOperators to the LSQR solver, which requires A and A^T. that's pretty much what I was thinking about ;-) I've actually started playing around with this option. Added RealVector operateTranspose(RealVector) to the RealLinearOperator abstract class. This method would be defined as optional in the Javadoc, with the option to throw an UnsupportedOperationException. I also thought about boolean isTransposable() to check at execution time that operateTranspose() has indeed been implemented. Not sure this method is absolutely necessary, though. Together with the comment from Ted, I think this is the best way to go. The isTransposable method may not be needed after all, I would be happy with a checked exception in case someone uses operateTranspose and it is not supported by the operator. Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-digester3 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-digester3 has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 18 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-digester3 : XML to Java Object Configuration - commons-digester3-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/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-digester3-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/digester/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html Work Name: build_apache-commons_commons-digester3 (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/digester] M2_HOME: /opt/maven2 - /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[28,26] package com.sun.mirror.util does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[37,15] cannot find symbol symbol: class AnnotationProcessor implements AnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[40,18] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[42,33] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[28,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[29,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[30,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[31,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[32,33] package com.sun.mirror.declaration does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[41,15] cannot find symbol symbol: class AnnotationProcessorFactory implements AnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[47,52] cannot find symbol symbol : class AnnotationTypeDeclaration location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[48,48] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory
[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-exec-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 23 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:/home/kk/grass/data/4404.he5://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.023 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.027 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.032 ms Process completed in 2005 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2004 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8018 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.867 sec FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Fri Jan 13 02:17:19 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1213012012, vmgump.apache.org:vmgump:1213012012 Gump E-mail Identifier (unique within run) #19. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
Yeah... but I am a fan of the UnsupportedOperationException so I think it should be OK to have something like that in the interface and just throw up if it is called. 2012/1/12 Sébastien Brisard sebastien.bris...@m4x.org 2012/1/12 Ted Dunning ted.dunn...@gmail.com: One such example is a text retrieval engine. A x is easy since that is what the engine does. A' y is very expensive. Thanks for this example! So you *do* agree that implementing operateTranspose() should be optional, don't you?
Re: [math] Transposable linear operators
Hi, That's true. So are you suggesting I should write three specialized classes InvertibleRealLinearOperator, TransposableRealLinearOperator, InvertibleAndTransposableRealLinearOperator? not really, I think such a structuring would create more confusion and problems in the long run than make up for the subtle differences that it may model right now. I agree. In fact, I'm now toying with the idea of removing InvertibleRealLinearOperator. I initially introduced this abstract class to handle preconditioners. In fact, if m is the preconditioner, instead of passing m to the solver (and calling m.solve(y)), I could just as well pass mInv = m^(-1) (and call mInv.operate(y)). Together with the comment from Ted, I think this is the best way to go. The isTransposable method may not be needed after all, I would be happy with a checked exception in case someone uses operateTranspose and it is not supported by the operator. Like Ted, I like UnsupportedOperationException, and do not really like catching unchecked exceptions. I hope you do not dislike the isTransposable() option too much? Last question (***to native english speakers***): I'm not sure isTransposable() really means what I would like it to mean. What do you think of boolean isTranspositionSupported()? Likewise, is this name OK RealVector operateTranspose(RealVector) considering that application of the real linear operator a is called RealVector operate(RealVector). Thanks for your help, Sébastien Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] Transposable linear operators
The shorter name is fine. Operate is a bit funky. A more traditional verb would be be apply() 2012/1/12 Sébastien Brisard sebastien.bris...@m4x.org Last question (***to native english speakers***): I'm not sure isTransposable() really means what I would like it to mean. What do you think of boolean isTranspositionSupported()? Likewise, is this name OK RealVector operateTranspose(RealVector) considering that application of the real linear operator a is called RealVector operate(RealVector).
Re: [math] Transposable linear operators
The shorter name is fine. isTransposable() it is, then! Operate is a bit funky. A more traditional verb would be be apply() Agreed. But this verb has been around for quite a time in the matrix context, so I just kept it for RealLinearOperator. Thanks for your interest in this issue, Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 337 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.002 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.034 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.03 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 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.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.188 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 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: Fri Jan 13 05:28:42 UTC 2012 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
Re: [DBUTILS] Few unit tests for BeanProcessor; none for SQLXML support
Oracle declared 1.5 EOL a good while back; ie) no security fixes; why should we encourage users to be on outdated versions? Especially as I think there are pretty big security issues unfixed in 1.5 (the magic floating number crash for example). If you're still on 1.5, you have worse problems than pieces of Commons throwing a ClassNotFound. I'm tempted to go as far as to say it's irresponsible of us to support 1.5 :) Hen On Thu, Jan 12, 2012 at 2:55 AM, sebb seb...@gmail.com wrote: On 12 January 2012 08:20, Henri Yandell flame...@gmail.com wrote: Tell me why 1.6 is a problem again? Because there are likely to be many companies still using Java 1.5 out there. I was hoping to fix the code so they are not prevented from using the new version. This is DB-helper code, so much less worried about use cases like Android. Hen On Fri, Jan 6, 2012 at 3:05 AM, sebb seb...@gmail.com wrote: I did some experimenting with BeanProcessor to see what would be involved in providing Java 1.5 support. As part of this, I tried commenting out the new code that requires Java 1.6. All tests still worked. I then commented out most of the rest of the else if clauses in the processColumn method, and the unit tests still worked. I think it might be fairly easy to recode the SQLXML section so it still works in Java 1.5, but without a proper unit test, this is difficult to prove. In any case, more unit tests are definitely needed. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] Supported Buildsystems of each component
On Thu, Jan 12, 2012 at 2:56 AM, sebb seb...@gmail.com wrote: On 12 January 2012 08:28, Henri Yandell flame...@gmail.com wrote: Couldn't we generate this? It feels like a very simple svn script to see if a component has a build.xml, pom.xml or project.xml. But that won't detect if the scripts actually still work. Agreed, but neither will the wiki. Unlike the wiki, it will detect when the build is removed. Not that I know how to integrate it into the website, but 'seems easy' :) Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: When to create a new major release - Was [VOTE][CANCEL] The vote for commons-email-1.3 based on RC2 in cancelled
On Thu, Jan 12, 2012 at 2:52 AM, sebb seb...@gmail.com wrote: On 12 January 2012 08:27, Henri Yandell flame...@gmail.com wrote: On Tue, Jan 10, 2012 at 10:19 AM, sebb seb...@gmail.com wrote: On 10 January 2012 16:45, Siegfried Goeschl sgoes...@gmx.at wrote: Hi folks, the main reason for the failed vote of commons-email-1.3 is that the release is only source but not binary compatible +) if you compile your application with the new version everything is fine +) if you replace simply the JAR the invocation fails Is it mandatory that a minor release is binary compatible with the previous one or do I have to create a new major version? There is a lot of ugly stuff (mainly protected member variables) which should be done but is currently not in the scope of this release. If the jar is not a drop-in replacement for the previous version, then yes, IMO that requires a major release. [1] The only possible exception might be if the incompatibilities are in internal parts of the API, i.e. classes/methods etc. that are not used externally. Thinking back on previous discussions, the primary exception has been the API itself is the bug and needs changing. A contrived (and over-simple) example would be: public void toUppercase(String s); It'd be better to fix the return type than live with bad API. Rare, but worth mentioning I thought. But that can still cause jar hell. If there are multiple jars in the same classloader that use the broken API, they will all have to be updated at the same time. May be tricky or impossible even if they are not from different providers. That's why binary compatibility is so important. Bad packaging practices causes jar hell. There's only so far we can go worrying about how our code is used. Part of the reason I felt it worth mentioning is that binary compatibility is not a magic trump card that aces everything else. It's very strongly desirable but not a mandatory absolute. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
