[jira] [Resolved] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tobias Bocanegra resolved JCRVLT-293.
-
Resolution: Fixed
Fix Version/s: 3.2
fixed in r1833680.
default build now executes both, jackrabbit and oak tests.
individual targets can be specified with {{-Ptest-oak}} or {{-Ptest-jackrabbit}}
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
> Fix For: 3.2
>
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495052#comment-16495052
]
Julian Reschke commented on JCRVLT-293:
---
[~anchela] - FWIW, there might be a JDK bug involved here. You probably should
update.
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16495044#comment-16495044
]
angela commented on JCRVLT-293:
---
[~reschke], i was using 1.8.0_40.
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494747#comment-16494747
]
Julian Reschke commented on JCRVLT-293:
---
With
java version "1.8.0_151"
and the patch for JCRVLT-294, the tests pass for me.
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494697#comment-16494697
]
Julian Reschke edited comment on JCRVLT-293 at 5/30/18 5:43 AM:
With JDK 1.8, I get:
{noformat}
---
Test set: org.apache.jackrabbit.vault.fs.io.DocViewFormatTest
---
Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.016 s <<<
FAILURE! - in org.apache.jackrabbit.vault.fs.io.DocViewFormatTest
testFormatting(org.apache.jackrabbit.vault.fs.io.DocViewFormatTest) Time
elapsed: 0.016 s <<< FAILURE!
java.lang.AssertionError
at
org.apache.jackrabbit.vault.fs.io.DocViewFormatTest.setup(DocViewFormatTest.java:48)
testFormatting(org.apache.jackrabbit.vault.fs.io.DocViewFormatTest) Time
elapsed: 0.016 s <<< ERROR!
java.lang.NullPointerException
at
org.apache.jackrabbit.vault.fs.io.DocViewFormatTest.tearDown(DocViewFormatTest.java:62)
{noformat}
See JCRVLT-294.
was (Author: reschke):
With JDK 1.8, I get:
{noformat}
---
Test set: org.apache.jackrabbit.vault.fs.io.DocViewFormatTest
---
Tests run: 2, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 0.016 s <<<
FAILURE! - in org.apache.jackrabbit.vault.fs.io.DocViewFormatTest
testFormatting(org.apache.jackrabbit.vault.fs.io.DocViewFormatTest) Time
elapsed: 0.016 s <<< FAILURE!
java.lang.AssertionError
at
org.apache.jackrabbit.vault.fs.io.DocViewFormatTest.setup(DocViewFormatTest.java:48)
testFormatting(org.apache.jackrabbit.vault.fs.io.DocViewFormatTest) Time
elapsed: 0.016 s <<< ERROR!
java.lang.NullPointerException
at
org.apache.jackrabbit.vault.fs.io.DocViewFormatTest.tearDown(DocViewFormatTest.java:62)
{noformat}
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494702#comment-16494702
]
Julian Reschke commented on JCRVLT-293:
---
With JDK 1.8 and {{oak=true}}, I see the same errors [~anchela] reported.
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16494662#comment-16494662
]
Tobias Bocanegra commented on JCRVLT-293:
-
which jdk version ?
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
[
https://issues.apache.org/jira/browse/JCRVLT-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
angela updated JCRVLT-293:
--
Description:
[~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by default
built against jackrabbit 2.x and spotted the _-Doak=true_ option. when build
agains Oak, i get the following tests failing:
{code}
[ERROR] Failures:
[ERROR]
RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR]
RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR] Errors:
[ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState OakState0001:
Unresolve...
{code}
The following test fails in both cases...
{code}
[ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
NoSuchField xdos...
{code}
is this expected or am i missing something?
was:
[~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by default
built against jackrabbit 2.x and spotted the _ -Doak=true_ option. when build
agains Oak, i get the following tests failing:
{code}
[ERROR] Failures:
[ERROR]
RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR]
RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR] Errors:
[ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState OakState0001:
Unresolve...
{code}
The following test fails in both cases...
{code}
[ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
NoSuchField xdos...
{code}
is this expected or am i missing something?
> Failing tests when building vault-core with -Doak=true
> --
>
> Key: JCRVLT-293
> URL: https://issues.apache.org/jira/browse/JCRVLT-293
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: Misc
>Reporter: angela
>Priority: Major
>
> [~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by
> default built against jackrabbit 2.x and spotted the _-Doak=true_ option.
> when build agains Oak, i get the following tests failing:
> {code}
> [ERROR] Failures:
> [ERROR]
> RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR]
> RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
> /testroot/dst/a/jcr:mixinTypes should not exist
> [ERROR] Errors:
> [ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState
> OakState0001: Unresolve...
> {code}
> The following test fails in both cases...
> {code}
> [ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
> NoSuchField xdos...
> {code}
> is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JCRVLT-293) Failing tests when building vault-core with -Doak=true
angela created JCRVLT-293:
-
Summary: Failing tests when building vault-core with -Doak=true
Key: JCRVLT-293
URL: https://issues.apache.org/jira/browse/JCRVLT-293
Project: Jackrabbit FileVault
Issue Type: Bug
Components: Misc
Reporter: angela
[~tripod], while investing JCRVLT-292 i noticed that _vault-core_ is by default
built against jackrabbit 2.x and spotted the _ -Doak=true_ option. when build
agains Oak, i get the following tests failing:
{code}
[ERROR] Failures:
[ERROR]
RCPTest.testMissingMixinWithNewer:212->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR]
RCPTest.testRemoveMixin:124->IntegrationTestBase.assertPropertyMissing:462
/testroot/dst/a/jcr:mixinTypes should not exist
[ERROR] Errors:
[ERROR] AdminPermissionCheckerTest.after:55 » InvalidItemState OakState0001:
Unresolve...
{code}
The following test fails in both cases...
{code}
[ERROR] TestPackageInstall.testPackageInstallWith0MtimeZipEntry:736 »
NoSuchField xdos...
{code}
is this expected or am i missing something?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: 1.3.4 blocked as failing tests
my fault, I¹m looking into it now On 17/08/15 12:02, Davide Giannella dav...@apache.org wrote: Hello team, trying to release Oak 1.3.4 but it's constantly failing on my local. Details can be found here https://issues.apache.org/jira/secure/attachment/12750782/oak-1.3.4-failin g-1439805620.log looking into it but if you know the answer ping me please. Davide
1.3.4 blocked as failing tests
Hello team, trying to release Oak 1.3.4 but it's constantly failing on my local. Details can be found here https://issues.apache.org/jira/secure/attachment/12750782/oak-1.3.4-failing-1439805620.log looking into it but if you know the answer ping me please. Davide
Re: 1.3.4 blocked as failing tests
On 17/08/2015 12:21, Stefan Egli wrote: my fault, I¹m looking into it now Thanks Stefan for the cooperation. However the build is still blocked as there are some pedantic issues I can't manage to clear. For some reasons even if I tell rat-pluing to ignore files in many ways it's ignoring my configuration. All the info for helping can be found here https://issues.apache.org/jira/browse/OAK-3173?focusedCommentId=14699533page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14699533 Thanks Davide
Failing tests
Hello everyone, I think all of us is aware of those but I have a fairly consistent failing test (first one at the end) and a more randomly failing one. Did a pull from upstream this morning as usual. While the second is randomly failing and not really blocking the build, the first one succeed probably only once in 5 builds. Cheers Davide java.lang.Exception: Results in target/sql2.txt don't match expected results in src/test/resources/sql2.txt; compare the files for details at org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:218) at org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest.sql2(SolrIndexQueryTest.java:86) 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:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) 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:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- Tests run: 2, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 0.089 sec FAILURE! concurrentUpdates(org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest) Time elapsed: 0.088 sec FAILURE! java.lang.AssertionError: expected:1000 but was:1010 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest.concurrentUpdates(ConcurrentConflictTest.java:189) at org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest.concurrentUpdates(ConcurrentConflictTest.java:83) 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:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
Re: Failing tests
Hi Davide, I'm looking into the Solr one. Regards, Tommaso 2014-03-31 10:55 GMT+02:00 Davide Giannella giannella.dav...@gmail.com: Hello everyone, I think all of us is aware of those but I have a fairly consistent failing test (first one at the end) and a more randomly failing one. Did a pull from upstream this morning as usual. While the second is randomly failing and not really blocking the build, the first one succeed probably only once in 5 builds. Cheers Davide java.lang.Exception: Results in target/sql2.txt don't match expected results in src/test/resources/sql2.txt; compare the files for details at org.apache.jackrabbit.oak.query.AbstractQueryTest.test(AbstractQueryTest.java:218) at org.apache.jackrabbit.oak.plugins.index.solr.query.SolrIndexQueryTest.sql2(SolrIndexQueryTest.java:86) 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:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) 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:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) -- Tests run: 2, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 0.089 sec FAILURE! concurrentUpdates(org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest) Time elapsed: 0.088 sec FAILURE! java.lang.AssertionError: expected:1000 but was:1010 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest.concurrentUpdates(ConcurrentConflictTest.java:189) at org.apache.jackrabbit.oak.plugins.document.ConcurrentConflictTest.concurrentUpdates(ConcurrentConflictTest.java:83) 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:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at
Failing tests on the DOCUMENT_JDBC
Hi, I have a test failing on the DOCUMENT_JDBC impl only (OAK-1472). Following the example from OAK-1488, I've enabled the test and added a clause to skip in the case of the above fixture. As far I can tell, this is not related to the test, so there's nothing I can do here, unless there's more info needed. Is there anything else I need to do to make sure this is visible? Should I maybe use a label, or a specific component. I have a TODO in the test code, but I doubt that is enough. thanks, alex
Re: failing tests
hi julian Julian Reschke wrote: - is anybody looking at these? - do we have JIRA issues (except JCR-1293 which seems to be something different)? i have been looking at the problem described in JCR-1293 and i assume that all the occasional failing tests are a result of the same problem (the one described in the mentioned bug). but i didn't have time yet to fix it, though i have some ideas how to get there. angela
failing tests
Hi, I can't help noticing that we currently seem to have *various* test cases that occasionally fail. This is very disturbing, because I'm a believer in not checking in new code until tests pass. With the current failures it's very hard to be sure that a change is good, and I fear that the longer we let the tests fail, the worse the situation will become (the broken window problem). In particular, I see failures in: testRestoreName(org.apache.jackrabbit.test.api.version.RestoreTest) testRemoveLabel(org.apache.jackrabbit.jcr2spi.version.LabelTest) testRevertReorderToEnd(org.apache.jackrabbit.jcr2spi.ReorderReferenceableSNSTest) So... - is anybody looking at these? - do we have JIRA issues (except JCR-1293 which seems to be something different)? BR, Julian
Re: failing tests
Hi, On Jan 21, 2008 5:01 PM, Julian Reschke [EMAIL PROTECTED] wrote: I can't help noticing that we currently seem to have *various* test cases that occasionally fail. This is very disturbing, because I'm a believer in not checking in new code until tests pass. +1 - is anybody looking at these? Not sure. I looked at them while preparing 1.4, but didn't have the cycles to come up with anything substantial so I just cut corners and disabled them for 1.4 as mentioned on JCR-1293. A more proper approach would have been to file real bug reports for the issues and have them recorded as known issues in the 1.4 release notes. - do we have JIRA issues (except JCR-1293 which seems to be something different)? Not that I know of. We should add a bug report about the failing tests after which it's OK to disable the tests as known issues. I'll do that tomorrow unless anyone beats me to it. BR, Jukka Zitting
