On 03/02/2015 15:53, Alex Parvulescu wrote: > [0] > Running org.apache.jackrabbit.oak.osgi.OSGiIT > [main] INFO org.ops4j.pax.exam.spi.DefaultExamSystem - Pax Exam System > (Version: 3.4.0) created. > [main] INFO org.ops4j.pax.exam.junit.impl.ProbeRunner - creating PaxExam > runner for class org.apache.jackrabbit.oak.osgi.OSGiIT > [main] INFO org.ops4j.pax.exam.junit.impl.ProbeRunner - running test class > org.apache.jackrabbit.oak.osgi.OSGiIT > ERROR: Bundle org.apache.jackrabbit.oak-jcr [20] Error starting > file:/home/buildslave3/slave3/oak-trunk/build/oak-it/osgi/target/test-bundles/oak-jcr.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.jackrabbit.oak-jcr [20]: Unable to resolve 20.0: missing > requirement [20.0] osgi.wiring.package; > (osgi.wiring.package=org.apache.jackrabbit.oak.plugins.atomic)) > org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.jackrabbit.oak-jcr [20]: Unable to resolve 20.0: missing > requirement [20.0] osgi.wiring.package; > (osgi.wiring.package=org.apache.jackrabbit.oak.plugins.atomic) > at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3974) > at org.apache.felix.framework.Felix.startBundle(Felix.java:2037) > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1291) > at > org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304) > at java.lang.Thread.run(Thread.java:662) > It didn't came up when I committed it; but the build failed for other reasons instead. I'll have a look.
One more reason for fixing our build first and at the same time if possible having the sponsorship. WRT to travis when I investigated the timeouts and the processes killed (error 137), I was told that now travis has a more robust deployment based on docker. Unfortunately it doesn't support sudo commands which will make impossible for our current status to run. We use apt-get install for mongo. there are workarounds on the above but I've never looked into it so I don't really know how much effort it will cost. We already split the profiles on travis and we can do the same apache buildbot. The point is that our tests will have to be instructed to be so. That's where the FixturesHelper come in (https://issues.apache.org/jira/browse/OAK-1855) In https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/test/java/org/apache/jackrabbit/oak/jcr/AtomicCounterIT.java a mixed approach where I instructed the test to run only if the profile is there and only on the Segment fixture specifically (in case of multiple fixtures where specified). I can take care of creating new profiles on travis, one per each persistence, it should be trivial but then all of us will have to act on each test instructing them to behave accordingly. For the apache buildbot it's a bit longer as I didn't look into it deeply yet. Thoughts? D.
