[continuum] BUILD FAILURE: Apache Commons - Commons Math -
Group (shared) Maven 2 Build Definition (Java 1.5) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 97 X-Continuum-Project-Name: Commons Math Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=27019projectId=97 Build statistics: State: Failed Previous State: Ok Started at: Fri 31 May 2013 11:20:13 + Finished at: Fri 31 May 2013 11:26:56 + Total time: 6m 42s Build Trigger: Schedule Build Number: 1271 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: ANSI_X3.4-1968 OS name: linux version: 2.6.32-41-server arch: amd64 Family: unix SCM Changes: Changed: erans @ Fri 31 May 2013 10:42:48 + Comment: MATH-985 Fixed wrong indexing. Unit tests that now fail set to @Ignore. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/analysis/interpolation/BicubicSplineInterpolatingFunction.java ( 1488145 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/analysis/interpolation/BicubicSplineInterpolatingFunctionTest.java ( 1488145 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.5 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 2.2.1 Description: Group (shared) Maven 2 Build Definition (Java 1.5) Test Summary: Tests: 5024 Failures: 3 Errors: 0 Success Rate: 99 Total time: 331.91318 Test Failures: TricubicSplineInterpolatorTest testPlane : java.lang.AssertionError java.lang.AssertionError: half-way between sample points (middle of the patch) expected:22.75 but was:22.0 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.commons.math3.analysis.interpolation.TricubicSplineInterpolatorTest.testPlane(TricubicSplineInterpolatorTest.java:137) testWave : java.lang.AssertionError java.lang.AssertionError: Half-way between sample points (middle of the patch) expected:-0.19600448825938194 but was:-0.09105346452437971 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.commons.math3.analysis.interpolation.TricubicSplineInterpolatorTest.testWave(TricubicSplineInterpolatorTest.java:201) BicubicSplineInterpolatorTest testPlane : java.lang.AssertionError java.lang.AssertionError: half-way between sample points (middle of the patch) expected:18.5 but was:20.5 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:443) at org.apache.commons.math3.analysis.interpolation.BicubicSplineInterpolatorTest.testPlane(BicubicSplineInterpolatorTest.java:115) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[jexl] Test failing with JUnit 4.11
Hi, I observed a test failure using JUnit 4.11 with the JEXL 2.x tests: Tests in error: testCalculations(org.apache.commons.jexl2.ArithmeticTest): org.apache.commons.jexl2.junit.Asserter.assertExpression@95![0,5]: '3 / 0;' divide error This doesn't happen with JUnit 4.10. JEXL 3 doesn't seem to be affected. After looking at the code I don't understand why the evaluation of the expression is affected by the version of JUnit used. What's the trick? Emmanuel Bourg signature.asc Description: OpenPGP digital signature
Re: [jexl] Test failing with JUnit 4.11
Le 31/05/2013 16:12, Gary Gregory a écrit : One thing to watch out for is that test method execution order is 'random'. Even the test methods for a given class? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
getting access to the components from my svn client
do i need user-id to download the components on the commons repo from my svn client ? if yes, how do i get the user-id and password ? thanks kunle
Re: [jexl] Test failing with JUnit 4.11
Yes, please see https://garygregory.wordpress.com/2013/01/23/understanding-junit-method-order-execution-updated-for-version-4-11/ Gary On Fri, May 31, 2013 at 10:30 AM, Emmanuel Bourg ebo...@apache.org wrote: Le 31/05/2013 16:12, Gary Gregory a écrit : One thing to watch out for is that test method execution order is 'random'. Even the test methods for a given class? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[Graph] Missing algorithms
Dear Bruno, He's willing to contribute to commons-graph too. Do you know if there's any algorithm that would be easier to implement and that no one is working on porting to commons-graph ATM, please? I'm not tracking a list of who is porting which algorithm to commons-graph. I think, that should be tracked in JIRA at https://issues.apache.org/jira/browse/SANDBOX-458, possibly as sub tasks :) What is not in the list, missing and IMHO easy to implement is A Simple, Fast Dominance Algorithm by Cooper, Keith D. and Harvey, Timothy J. and Kennedy, Ken. There is an GPL implementation based on JGraphT (com.jopdesign.wcet.graphutils.DominatorsV, E), but I'm currently not finding the source itself. Since Apache does not want to be infected by GPL code, it might be better to just implement the paper :) Cheers, Oliver - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Test failing with JUnit 4.11
Gary Gregory wrote: Yes, please see https://garygregory.wordpress.com/2013/01/23/understanding-junit-method-order-execution-updated-for-version-4-11/ ... and ... http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runOrder Personally I use always random order in my tests. Otherwise you might not be able to run individual fixtures r.g. in Eclipse or parallel execution is also not possible. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1488301 - /commons/proper/ognl/trunk/doap_ognl.rdf
Nice catch, looks like project is wrong as well Project rdf:about=http://commons.apache.org/fileupload/; Maurizio Cucchiara - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1488301 - /commons/proper/ognl/trunk/doap_ognl.rdf
On 31 May 2013 17:38, Maurizio Cucchiara mcucchi...@apache.org wrote: Nice catch, looks like project is wrong as well Project rdf:about=http://commons.apache.org/fileupload/; Rats - thought I'd found all the references; now fixed. Maurizio Cucchiara - 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: [Followup][Graph] the future of commons-graph and modularization
Hi Simo! I liked the project structure, it's looking like the new structure that Matt created in commons-functor [1], with a API project, one module for each algorithm family and other modules for utility projects, like benchmark tests. I think we'll have to update the website, since now under Project Documentation / Project Modules, the links to the submodules pages are broken. So kudos for the great work and my +1 for the modularization of commons-graph. Since I'm not very familiar with commons-graph code base and haven't used it in any project yet, probably other's comments will be important on this thread too. Side note, I noticed that there are some TODO's, mainly in Javadocs. So I've set up a job in Jenkins [2] with the Maven site + open tasks (FIXME, TODO and TBD). I'll read the open tasks later to see if I can work on any of them, but I think I'll wait for the modularization branch to be merged first :) Cheers [1] http://svn.apache.org/viewvc/commons/proper/functor/trunk/ [2] http://builds.tupilabs.com/job/commons-graph-modularization/1/tasksResult/ Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com --- Em ter, 28/5/13, Simone Tripodi simonetrip...@apache.org escreveu: De: Simone Tripodi simonetrip...@apache.org Assunto: [Followup][Graph] the future of commons-graph and modularization Para: Commons Developers List dev@commons.apache.org Data: Terça-feira, 28 de Maio de 2013, 12:06 Hi all guys, here it is my proposal[1], see r1486948. It has been quiet hard since he did not think in therms of separated modules, so I took the freedom to relocate some classes here and there. It is a experimental branch anyway, the purpose is just demonstrating the PoC. Looking forward to read your feedbacks! Many thanks in advance, all the best, -Simo [1] http://svn.apache.org/repos/asf/commons/sandbox/graph/branches/modularization/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, May 26, 2013 at 5:35 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all, mates, after a long while I haven't touched commons-graph, I had the opportunity to get influenced by some activities at my paid work that made me think twice on what as been already done in that component, and would like to bring new experiences in. So, what I still like about it: * graph APIs: the use of generics make the usage of graphes extensible and adaptable; * fluent APIs: this is the most powerful feature IMHO that simplifies the APIs usage; What I *don't* like anymore: * poor modularization: commons-graph is ATM a big fat monolith; * one single entry-point; for each new family of algorithm(s), new methods have to be added in the main Commons-Graph class. What I would like to propose to work _in a separated branch_, is trying to split the big monolith in smaller modules and separate APIs from related implementation as much as possible. Questions are: * WDYT? :) * About release process: would it be acceptable, here in commons, release a single module - the only one that has been changed, I mean - without releasing the whole project? * In case the answer to previous question is no, would it make sense moving commons-graph to the Incubator (and possibly to TLP)? TIA, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Test failing with JUnit 4.11
Looks like the problem might be the engine settings; divide by 0 will throw an error in strict mode (lenient=false) So if tests use a mix of modes, it's possible that the wrong mode will be left around. The JEXL engine is not immutable, and is shared between some tests, so this can easily happen. On 31 May 2013 16:36, Jörg Schaible joerg.schai...@scalaris.com wrote: Gary Gregory wrote: Yes, please see https://garygregory.wordpress.com/2013/01/23/understanding-junit-method-order-execution-updated-for-version-4-11/ ... and ... http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runOrder Personally I use always random order in my tests. Otherwise you might not be able to run individual fixtures r.g. in Eclipse or parallel execution is also not possible. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [chain] improving current registry and configuration APIs
Hi again, Simo and I had a chat about chain lately. We agreed on the points he has already mentioned (see below). Some additional issues that we came across: * The xml module has dependencies to digister. This should be removed if possible * Base classes of the API are currently in o.a.c.c.core.impl package. This is awkward, because the base classes really belong to the API. I came across this issue while trying to create a test for o.a.c.c.Chains. I'm not able to use ChainBase in that test because it is in another module (the core module). As a first step for me to get used to the API, I'd like to to move convenient base classes like ChainBase and CommandBase to the API package. WDYT? Benedikt Am 27.05.2013 um 09:31 schrieb Simone Tripodi simonetrip...@apache.org: Hi all Chain-ers, I had yet another small review yesterday[1] at current Configuration APIs and I am not satisfied yet for the following reasons: * org.apache.commons.chain2.CatalogFactory should maybe moved from `core` module to the `api` module; * org.apache.commons.chain2.CatalogFactory is an abstract class, but the static `getInstance()` method relies to a specific concrete implementation; * org.apache.commons.chain2.CatalogFactory mixes the concept of Factory and Registry - more I read that codebase, more I get confused, IMHO it should be split in two different classes with two different roles; * after introducing the configuration facade APIs, org.apache.commons.chain2.CatalogFactory#checkForValidConfigurationModule() lost its purpose - I suggest to drop it and make the CatalogFactory completely un-aware of the existence of the configuration. * the most confusing part is still, IMHO, how the config APIs work: the org.apache.commons.chain2.config.ConfigParser#parse(URL) method parses a textual format of Chain representation and populates org.apache.commons.chain2.CatalogFactory retrieving the static singleton instance and populate it... IMHO, it would be easier if the `parse(URL)` method just returns a CatalogFactory instance. This is just to start, I think much more will come when I'll have another look at current codebase. Now, the question is: is there any committer(s)/contributor(s) that can/wishes to help on the Chain component? Due to my reduced spare time slot, I cannot handle it all alone and it would be good, after more than one year of work, speaking about an RC :) Many thanks in advance, all the best! -Simo [1] http://svn.apache.org/viewvc?view=revisionrevision=1486478 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [jexl] Test failing with JUnit 4.11
Le 31/05/2013 19:14, sebb a écrit : Looks like the problem might be the engine settings; divide by 0 will throw an error in strict mode (lenient=false) That's the missing piece of the puzzle. testDivideByZero is declared after testCalculations but is executed before with JUnit 4.11. testDivideByZero sets lenient=false, thus causing testCalculations to fail. Setting lenient=true at the beginning of testCalculations solves the issue, JEXL 3 already does that. Thanks all for your help! Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
