jackrabbit-oak build #3209: Broken
Build Update for apache/jackrabbit-oak - Build: #3209 Status: Broken Duration: 1874 seconds Commit: 97b2a36af5139ebe673eb86fa6218bc34365fe84 (trunk) Author: Jukka Zitting Message: OAK-1332: Large number of changes to the same node can fill observation queue Improved deferral of node change processing when the diff queue limit is reached git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562361 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/d420ce0d7929...97b2a36af513 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17817470 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3208: Fixed
Build Update for apache/jackrabbit-oak - Build: #3208 Status: Fixed Duration: 2569 seconds Commit: d420ce0d792902a6c7ff74764c54fdf8c55470e6 (trunk) Author: Jukka Zitting Message: OAK-1332: Large number of changes to the same node can fill observation queue Optimize and clean up the code for detecting reorderings git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562360 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/9c6d43e85236...d420ce0d7929 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17816807 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3207: Fixed
Build Update for apache/jackrabbit-oak - Build: #3207 Status: Fixed Duration: 2492 seconds Commit: 9c6d43e8523629dbe1d3faf4a6477d7d75608421 (trunk) Author: Jukka Zitting Message: OAK-1332: Large number of changes to the same node can fill observation queue Fix failing NodeReorderTest git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562352 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/ce01d677bc3c...9c6d43e85236 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17815553 -- sent by Jukka's Travis notification gateway
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4243 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562352 Blamelist: jukka Build succeeded! sincerely, -The Buildbot
Re: buildbot failure in ASF Buildbot on oak-trunk
Hi, On Tue, Jan 28, 2014 at 9:04 PM, wrote: > The Buildbot has detected a new failure on builder oak-trunk while building > ASF Buildbot. > Full details are available at: > http://ci.apache.org/builders/oak-trunk/builds/4242 Oops, my bad. Fixing it now. BR, Jukka Zitting
jackrabbit-oak build #3206: Broken
Build Update for apache/jackrabbit-oak - Build: #3206 Status: Broken Duration: 1453 seconds Commit: ce01d677bc3c852171c90294c43351d61d598e41 (trunk) Author: Jukka Zitting Message: OAK-1332: Large number of changes to the same node can fill observation queue Implement rate-limiting to of ChangeListener callbacks, as mentioned in the issue git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562341 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/05c8ca029b46...ce01d677bc3c View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17809266 -- sent by Jukka's Travis notification gateway
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4242 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562341 Blamelist: jukka BUILD FAILED: failed compile sincerely, -The Buildbot
Re: Separating API/SPI in different bundles (was: svn commit: r1561926 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/pom.xml)
Hi, On Tue, Jan 28, 2014 at 2:32 PM, Tobias Bocanegra wrote: > I also think that the amount of exported packages is very large. It > looks like we didn't really know how to modularize oak and just > exported basically everything :-) That's a pretty broad statement. Yes, there are a few cases where the package-level dependencies should be fixed to avoid exporting too many details, but most of the exported packages don't fall into this category. In fact one could come to the exact opposite conclusion: a modular system necessarily exports lots of packages. At least one package for each distinct extension point and often a supporting package of base classes and utility code related to that extension point. Just look at the number of exported packages in a Sling system. Instead of splitting code to separate API/SPI bundles (What would the SPI bundle be anyway? Instead of one monolithic facade, the Oak SPI consists of various more or less independent extension points, whose main shared feature is just that they're used by oak-core, making a standalone SPI bundle an odd construct.), a more productive approach would IMHO be to look at the exports individually and refactor the code to fix cases where an export shouldn't exist. BR, Jukka Zitting
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4239 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562301 Blamelist: tripod Build succeeded! sincerely, -The Buildbot
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4238 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562233 Blamelist: jukka BUILD FAILED: failed compile sincerely, -The Buildbot
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4237 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562231 Blamelist: jukka Build succeeded! sincerely, -The Buildbot
Re: svn commit: r1561925 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/
On Tue, Jan 28, 2014 at 11:32 AM, Jukka Zitting wrote: > Hi, > > On Tue, Jan 28, 2014 at 2:20 PM, Tobias Bocanegra wrote: >> as i mentioned before. it's not a branch nor a tag of an official >> release, but merely a place to record that I intended to use a 0.15.2 >> version of oak-core. > > I think it would be clearer if you moved it from tags/ to branches/, > as all the other tags correspond to official releases. right. I'll do that. thanks. regards, toby
Re: svn commit: r1561925 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/
Hi, On Tue, Jan 28, 2014 at 2:20 PM, Tobias Bocanegra wrote: > as i mentioned before. it's not a branch nor a tag of an official > release, but merely a place to record that I intended to use a 0.15.2 > version of oak-core. I think it would be clearer if you moved it from tags/ to branches/, as all the other tags correspond to official releases. BR, Jukka Zitting
Separating API/SPI in different bundles (was: svn commit: r1561926 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/pom.xml)
Hi, On Tue, Jan 28, 2014 at 1:54 AM, Chetan Mehrotra wrote: > On Tue, Jan 28, 2014 at 7:41 AM, wrote: >> + org.apache.jackrabbit.oak;version="0.15.0", >> + org.apache.jackrabbit.oak.api;version="0.15.0", >> + org.apache.jackrabbit.oak.api.jmx;version="0.15.0", > > We should version packages independent of Oak release version. definitely! > Probably a better way would be to > > 1. Add explicit package-info.java with correct bnd version > annotations. Then we need not explicitly list down package names in > pom.xml yes. I always wanted to do this, but was too lazy/busy in the end. I created https://issues.apache.org/jira/browse/OAK-1362 to track this. > 2. Untill we have a 1.0 release we can set the package version to > 1.0.0 and not change it if even if any API changes considering that > pre 1.0 builds are to be considered as unstable wrt API right. > Post 1.0 we take care to bump the version as per OSGi Sematic Version > guidelines [1] definitely. I also think that the amount of exported packages is very large. It looks like we didn't really know how to modularize oak and just exported basically everything :-) I suggest to separate some API (and SPI) bits into separate bundles (see OAK-1238 and OAK-1239). This certainly raises awareness of the modularization also for non-osgi setups. regards, toby > > Chetan Mehrotra > [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
Re: svn commit: r1561925 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/
Hi, On Tue, Jan 28, 2014 at 1:11 AM, Alex Parvulescu wrote: > Hi, > > Shouldn't these changes go into trunk directly? I only see then on the new > branch. no, they are in trunk. I added them here: https://svn.apache.org/viewvc?view=revision&revision=1560563 > Second, I did not see any kind of discussion/announcement related to this > new branch. We create releases every 2 weeks, couldn't this have waited a > few days? as i mentioned before. it's not a branch nor a tag of an official release, but merely a place to record that I intended to use a 0.15.2 version of oak-core. I could have done it in my private fork, but didn't. As soon as 0.16 is released, I delete the tag again. regards, toby > best, > alex > > > > > On Tue, Jan 28, 2014 at 6:26 AM, Tobias Bocanegra wrote: > >> Hi, >> >> > On Mon, Jan 27, 2014 at 9:08 PM, wrote: >> >> creating tag for oak-core 0.15.2 with modified manifest entries >> > >> > Are we releasing 0.15.2? >> >> No. I just needed an updated oak-core jar that contained a slightly >> different MANIFEST.MF for exported packages that I forgot to include >> in the official 0.15 release. And I thought it's best if I record this >> change as non-released oak tag. I don't think we ever need to release >> 0.15.2++ officially. but if we do, we need to create a 0.15 branch >> anyways and then release 0.15.4. >> >> The alternative would have been to create a release my own fork...but >> this would have not been as transparent, in case we really need to >> release 0.15.x. >> >> regards, toby >> >> > >> > BR, >> > >> > Jukka Zitting >>
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4236 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562102 Blamelist: jukka BUILD FAILED: failed compile sincerely, -The Buildbot
new test failures
Hi there, with the current trunk, I occasionally get the test failure below (oak-core): --- Test set: org.apache.jackrabbit.oak.plugins.document.RevisionTest --- Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.112 sec <<< FAILURE! difference(org.apache.jackrabbit.oak.plugins.document.RevisionTest) Time elapsed: 0.034 sec <<< FAILURE! java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.jackrabbit.oak.plugins.document.RevisionTest.difference(RevisionTest.java:55) 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.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.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) 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:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) Is it just me? Best regards, Julian
Re: Adding a 'restore' method to the NodeStore apis
Hi, On Tue, Jan 28, 2014 at 9:30 AM, Alex Parvulescu wrote: > This assumption was challenged via OAK-1357 with the idea that the MongoDB > backup can already produce consistent (non-blocking) backups so there's > nothing to be done in this area. "MMS Backup offers point in time recovery of MongoDB replica sets and a consistent snapshot of sharded systems." http://docs.mongodb.org/manual/core/backups/ Alternatively, if the external database (MongoDB, or other) doesn't support consistent backups, I'd argue that it's better *not* to use the external backup mechanism and instead do an Oak-level backup to a TarMK repository. BR, Jukka Zitting
Re: Adding a 'restore' method to the NodeStore apis
Hi, re > This assumption was challenged via OAK-1357 with the idea that the MongoDB > backup can already produce consistent (non-blocking) backups so there's > nothing to be done in this area. Also restoring means only replacing the > old db with the backup one. I am not sure if MongoDB is able to produce a consistent backup as it cannot be aware of Oak’s document model. For example, a consistent revision might involve changes to documents located in /content (in Oak’s POV) and also the corresponding index nodes. There is one caveat (and I actually might be wrong with the above): afaik Oak commits the new revision as the last document to MongoDB. If MongoMK can guarantee that and additionally guarantee that any changes that are committed without the corresponding revision-ID-commit we might be able to do without explicitly marking a checkpoint. Michael On 28 Jan 2014, at 15:30, Alex Parvulescu wrote: > Hi, > > I'm back trying to gather some feedback from the people involved in the > MongoDB store impl. > > This is about creating a backup of the current repository using a native > backup tool, a tool that is running at databasel level. > It was my understanding that if you run a (non blocking) backup at any > given time, you might catch a repository in an inconsistent state (large > transactions half-way completed maybe?), so you might need a way to mark > the latest stable head before basically copying everything. > Next on restore you would simply need to reset the head to the last known > stable state and you get the full circle. > > I've found that the checkpoint mechanism we use for the async indexing fits > this model nicely, and I was planning on using it in this context as well: > marking the last state with a checkpoint, then using the same checkpoint id > as a reference for the restore. > This would work both in the case of a MongoDB store (also the RDB one) but > also in the cases where the repository is too big and out backup code > cannot handle it efficiently (think huge repo + file system snapshots). > > This assumption was challenged via OAK-1357 with the idea that the MongoDB > backup can already produce consistent (non-blocking) backups so there's > nothing to be done in this area. Also restoring means only replacing the > old db with the backup one. > > If this is true, I'm as happy as it gets, I can already close down a bunch > of issues :) but I want clear confirmation that this is in fact the way it > works and that everybody agrees with it and so there are no loose ends. > > thanks for your attention, > alex > > > > > > On Mon, Jan 27, 2014 at 1:22 PM, Alex Parvulescu > wrote: > >> Hi, >> >> I've created OAK-1357 asking for a new method on the NodeStore apis: >> 'restore', please add your thoughts to the issue. >> >> thanks, >> alex >>
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4232 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562076 Blamelist: angela Build succeeded! sincerely, -The Buildbot
Re: Adding a 'restore' method to the NodeStore apis
Hi, I'm back trying to gather some feedback from the people involved in the MongoDB store impl. This is about creating a backup of the current repository using a native backup tool, a tool that is running at databasel level. It was my understanding that if you run a (non blocking) backup at any given time, you might catch a repository in an inconsistent state (large transactions half-way completed maybe?), so you might need a way to mark the latest stable head before basically copying everything. Next on restore you would simply need to reset the head to the last known stable state and you get the full circle. I've found that the checkpoint mechanism we use for the async indexing fits this model nicely, and I was planning on using it in this context as well: marking the last state with a checkpoint, then using the same checkpoint id as a reference for the restore. This would work both in the case of a MongoDB store (also the RDB one) but also in the cases where the repository is too big and out backup code cannot handle it efficiently (think huge repo + file system snapshots). This assumption was challenged via OAK-1357 with the idea that the MongoDB backup can already produce consistent (non-blocking) backups so there's nothing to be done in this area. Also restoring means only replacing the old db with the backup one. If this is true, I'm as happy as it gets, I can already close down a bunch of issues :) but I want clear confirmation that this is in fact the way it works and that everybody agrees with it and so there are no loose ends. thanks for your attention, alex On Mon, Jan 27, 2014 at 1:22 PM, Alex Parvulescu wrote: > Hi, > > I've created OAK-1357 asking for a new method on the NodeStore apis: > 'restore', please add your thoughts to the issue. > > thanks, > alex >
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4231 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562067 Blamelist: mreutegg BUILD FAILED: failed compile sincerely, -The Buildbot
jackrabbit-oak build #3185: Passed
Build Update for apache/jackrabbit-oak - Build: #3185 Status: Passed Duration: 2606 seconds Commit: 952503582d960db1f82eb4f2ee91badfd65c182f (trunk) Author: Angela Schreiber Message: OAK-919: test-case OAK-915: enable tests git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562027 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/a555fd75bf7e...952503582d96 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17757913 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3184: Passed
Build Update for apache/jackrabbit-oak - Build: #3184 Status: Passed Duration: 2285 seconds Commit: a555fd75bf7eca02bed29024678f88236f99abd7 (trunk) Author: Marcel Reutegger Message: OAK-1360: Rename o.a.j.o.plugins.mongomk to o.a.j.o.plugins.document - move DocumentStore implementations to separate packages git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562024 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/8a335b87c058...a555fd75bf7e View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17757204 -- sent by Jukka's Travis notification gateway
buildbot success in ASF Buildbot on oak-trunk
The Buildbot has detected a restored build on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4225 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562024 Blamelist: mreutegg Build succeeded! sincerely, -The Buildbot
RE: jackrabbit-oak build #3183: Errored
the build output says: [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (findbugs) @ oak-mk-remote --- [INFO] Fork Value is true No output has been received in the last 10 minutes, this potentially indicates a stalled build or something wrong with the build itself. The build has been terminated Looks unrelated to my changes. May be a transient issue... Regards Marcel > -Original Message- > From: Travis CI [mailto:ju...@apache.org] > Sent: Dienstag, 28. Januar 2014 11:09 > To: oak-dev@jackrabbit.apache.org > Subject: jackrabbit-oak build #3183: Errored > > Build Update for apache/jackrabbit-oak > - > > Build: #3183 > Status: Errored > > Duration: 783 seconds > Commit: 8a335b87c058de3604809f92ce9faa8eb995ce2c (trunk) > Author: Marcel Reutegger > Message: OAK-1360: Rename o.a.j.o.plugins.mongomk to > o.a.j.o.plugins.document > - rename package > > git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562019 > 13f79535-47bb-0310-9956-ffa450edef68 > > View the changeset: https://github.com/apache/jackrabbit- > oak/compare/5eaad1d99f41...8a335b87c058 > > View the full build log and details: https://travis-ci.org/apache/jackrabbit- > oak/builds/17754893 > > -- > sent by Jukka's Travis notification gateway
RE: buildbot failure in ASF Buildbot on oak-trunk
Tests in error: testRegisterCustomPrivileges(org.apache.jackrabbit.oak.jcr.security.privilege.PrivilegeRegistrationTest): Java heap space happened after I started to refactore the mongomk packages. Let's see if the build still fails when I'm finished with my changes... Regards Marcel
jackrabbit-oak build #3183: Errored
Build Update for apache/jackrabbit-oak - Build: #3183 Status: Errored Duration: 783 seconds Commit: 8a335b87c058de3604809f92ce9faa8eb995ce2c (trunk) Author: Marcel Reutegger Message: OAK-1360: Rename o.a.j.o.plugins.mongomk to o.a.j.o.plugins.document - rename package git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1562019 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/5eaad1d99f41...8a335b87c058 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/17754893 -- sent by Jukka's Travis notification gateway
Re: svn commit: r1561926 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/pom.xml
On Tue, Jan 28, 2014 at 7:41 AM, wrote: > + org.apache.jackrabbit.oak;version="0.15.0", > + org.apache.jackrabbit.oak.api;version="0.15.0", > + org.apache.jackrabbit.oak.api.jmx;version="0.15.0", We should version packages independent of Oak release version. Probably a better way would be to 1. Add explicit package-info.java with correct bnd version annotations. Then we need not explicitly list down package names in pom.xml 2. Untill we have a 1.0 release we can set the package version to 1.0.0 and not change it if even if any API changes considering that pre 1.0 builds are to be considered as unstable wrt API Post 1.0 we take care to bump the version as per OSGi Sematic Version guidelines [1] Chetan Mehrotra [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure on builder oak-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/oak-trunk/builds/4224 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: osiris_ubuntu Build Reason: scheduler Build Source Stamp: [branch jackrabbit/oak/trunk] 1562019 Blamelist: mreutegg BUILD FAILED: failed compile sincerely, -The Buildbot
Re: svn commit: r1561925 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/
Hi, Shouldn't these changes go into trunk directly? I only see then on the new branch. Second, I did not see any kind of discussion/announcement related to this new branch. We create releases every 2 weeks, couldn't this have waited a few days? best, alex On Tue, Jan 28, 2014 at 6:26 AM, Tobias Bocanegra wrote: > Hi, > > > On Mon, Jan 27, 2014 at 9:08 PM, wrote: > >> creating tag for oak-core 0.15.2 with modified manifest entries > > > > Are we releasing 0.15.2? > > No. I just needed an updated oak-core jar that contained a slightly > different MANIFEST.MF for exported packages that I forgot to include > in the official 0.15 release. And I thought it's best if I record this > change as non-released oak tag. I don't think we ever need to release > 0.15.2++ officially. but if we do, we need to create a 0.15 branch > anyways and then release 0.15.4. > > The alternative would have been to create a release my own fork...but > this would have not been as transparent, in case we really need to > release 0.15.x. > > regards, toby > > > > > BR, > > > > Jukka Zitting >
Re: Support for Jackrabbit 2.x DataStores
Hi, >Are there better ways of doing this? for example as suggested by Thomas to >use the repository.xml to read the datastore configuration. Yes, I think that would be the most user friendly approach, specially for migration of Jackrabbit 2.x repositories. But I'm not sure how easy it is to implement it. Jukka, I wonder how does the current migration work? Does it support the repository.xml file? Regards, Thomas
Re: jackrabbit-oak build #3173: Broken
On 28.1.14 8:39 , Marcel Reutegger wrote: Hi, Failed tests: addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT): javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /test/node4 This doesn't seem to be related to my changes. Anyone else seen such before? Does the content contributed by the test case actually ensure that no conflicts arise? Otherwise such an exception is actually to be expected and we should change the test. the test may cause conflicts in the property index. the expectation is that node store implementations are able to deal with those conflicts introduced by commit editors and retry the merge. maybe in this case one thread was unfortunate on each retry and eventually failed the merge. So the failure would still be expected in this case but rather difficult to distinguish from non expected merge failures. Let's keep an eye on this to see whether we need to do something about it. Michael Regards Marcel
Re: jackrabbit-oak build #3173: Broken
On 28.1.14 8:39 , Marcel Reutegger wrote: Hi, Failed tests: addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT): javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /test/node4 This doesn't seem to be related to my changes. Anyone else seen such before? Does the content contributed by the test case actually ensure that no conflicts arise? Otherwise such an exception is actually to be expected and we should change the test. the test may cause conflicts in the property index. the expectation is that node store implementations are able to deal with those conflicts introduced by commit editors and retry the merge. maybe in this case one thread was unfortunate on each retry and eventually failed the merge. So the failure would still be expected in this case but rather difficult to distinguish from non expected merge failures. Let's keep an eye on this to see whether we need to do something about it. Michael Regards Marcel
Re: jackrabbit-oak build #3173: Broken
On 28.1.14 8:39 , Marcel Reutegger wrote: Hi, Failed tests: addNodes[2](org.apache.jackrabbit.oak.jcr.ConcurrentAddIT): javax.jcr.InvalidItemStateException: OakState0001: Unresolved conflicts in /test/node4 This doesn't seem to be related to my changes. Anyone else seen such before? Does the content contributed by the test case actually ensure that no conflicts arise? Otherwise such an exception is actually to be expected and we should change the test. the test may cause conflicts in the property index. the expectation is that node store implementations are able to deal with those conflicts introduced by commit editors and retry the merge. maybe in this case one thread was unfortunate on each retry and eventually failed the merge. So the failure would still be expected in this case but rather difficult to distinguish from non expected merge failures. Let's keep an eye on this to see whether we need to do something about it. Michael Regards Marcel
Support for Jackrabbit 2.x DataStores
Hi, I have been working on enabling Jackrabbit data stores in OAK (tracked via OAK-805, OAK-1157). I need some clarification on how best to support the configuration needed for these DataStores in OAK. How that is done in my current implementation is to have separate configuration objects created which limits extensibility. Are there better ways of doing this? for example as suggested by Thomas to use the repository.xml to read the datastore configuration. Thanks Amit
