[Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 772 - Still Failing
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build #772) Status: Still Failing Check console output at https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/772/ to view the results. Changes: [tommaso] OAK-4068 - adapted IndexDefinitionTest to new default of 10 mins [chetanm] OAK-4010 - Log major operation done in Oak via specific operation logger [tommaso] OAK-4068 - reverted previous bad commit [tommaso] OAK-4068 - adapted IndexDefinitionTest to new default of 10 mins [chetanm] OAK-4071 - Include node path in VersionException [davide] OAK-4072 - Update Jackrabbit version to 2.12.1 [jsedding] OAK-3844 - Better support for versionable nodes without version [jsedding] OAK-3844 - Better support for versionable nodes without version [catholicon] OAK-4066: Suggestion dictionary don't update after Test results: 26 tests failed. FAILED: org.apache.jackrabbit.oak.osgi.OSGiIT.listServices Error Message: gave up waiting for service javax.jcr.Repository Stack Trace: org.ops4j.pax.swissbox.tracker.ServiceLookupException: gave up waiting for service javax.jcr.Repository at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:199) at org.ops4j.pax.swissbox.tracker.ServiceLookup.getService(ServiceLookup.java:136) at org.ops4j.pax.exam.inject.internal.ServiceInjector.injectField(ServiceInjector.java:89) at org.ops4j.pax.exam.inject.internal.ServiceInjector.injectDeclaredFields(ServiceInjector.java:69) at org.ops4j.pax.exam.inject.internal.ServiceInjector.injectFields(ServiceInjector.java:61) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.createTest(ContainerTestRunner.java:60) at org.junit.runners.BlockJUnit4ClassRunner$1.runReflectiveCall(BlockJUnit4ClassRunner.java:244) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.BlockJUnit4ClassRunner.methodBlock(BlockJUnit4ClassRunner.java:241) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:67) at org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:37) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at org.junit.runner.JUnitCore.run(JUnitCore.java:138) at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:125) at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:98) at org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:74) at org.ops4j.pax.exam.nat.internal.NativeTestContainer.call(NativeTestContainer.java:108) at org.ops4j.pax.exam.spi.reactors.EagerSingleStagedReactor.invoke(EagerSingleStagedReactor.java:109) at org.ops4j.pax.exam.junit.impl.ProbeRunner$2.evaluate(ProbeRunner.java:278) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.ops4j.pax.exam.junit.impl.ProbeRunner.run(ProbeRunner.java:112) at org.ops4j.pax.exam.junit.PaxExam.run(PaxExam.java:93) 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:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method
[Oak origin/1.0] Apache Jackrabbit Oak matrix - Build # 771 - Still Failing
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#771)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/771/ to view
the results.
Changes:
[dj] Apache Jackrabbit Oak 1.0.28 release notes
[dj] [maven-release-plugin] prepare release jackrabbit-oak-1.0.28
[dj] [maven-release-plugin] prepare for next development iteration
Test results:
4 tests failed.
FAILED: org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql
Error Message:
expected:<[[{term=in 2015 a red fox is still a fox,weight=1}, {term=in 2015 my
fox is red, like mike's fox and john's fox,weight=1}]]> but was:<[]>
Stack Trace:
junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is still
a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and john's
fox,weight=1}]]> but was:<[]>
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at
org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestSql(SuggestTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
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:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
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)
FAILED: org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath
Error Message:
expected:<[[{term=in 2015 a red fox is still a fox,weight=1}, {term=in 2015 my
fox is red, like mike's fox and john's fox,weight=1}]]> but was:<[]>
Stack Trace:
junit.framework.ComparisonFailure: expected:<[[{term=in 2015 a red fox is still
a fox,weight=1}, {term=in 2015 my fox is red, like mike's fox and john's
fox,weight=1}]]> but was:<[]>
at junit.framework.Assert.assertEquals(Assert.java:100)
at junit.framework.Assert.assertEquals(Assert.java:107)
at junit.framework.TestCase.assertEquals(TestCase.java:269)
at
org.apache.jackrabbit.oak.jcr.query.SuggestTest.testSuggestXPath(SuggestTest.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:464)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at
org.junit.internal.runners.JUnit38Class
Re: [Blocked] Re: Oak 1.3.17/1.4.0 release plan
> https://issues.apache.org/jira/browse/OAK-4066 This issue is resolved now.
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
[X] +1 Release this package as Apache Jackrabbit Oak 1.0.28 Davide
Re: testing blob equality
Hi Julian, > On 29 Feb 2016, at 15:40, Julian Sedding wrote: > > Should we automatically wrap the DS in the LengthCachingDatastore in > oak-upgrade? Or provide an option for the cache-file path, which turns > it on if set? Good idea. I think we should enable it by default (to limit the number of parameters required to perform a “standard” migration). We may also add the parameter to change cache-file location. I created OAK-4074 to track this. Best regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com
Re: testing blob equality
Yes, the LengthCachingDataStore is exactly the way to go. You need to wrap the original datastore in the length caching datastore (using the repository.xml). The LengthCachingDataStore not only caches the length, but (for the FileDataStore at least) it also prevents a call to File.exists(). These add up on the FS and I expect even more so on S3. Should we automatically wrap the DS in the LengthCachingDatastore in oak-upgrade? Or provide an option for the cache-file path, which turns it on if set? Regards Julian On Mon, Feb 29, 2016 at 3:17 PM, Tomek Rekawek wrote: > Thanks Chetan, I haven’t noticed the length() invocation in the createBlob(). > It seems that the LengthCachingDataStore is something I was looking for. > > Best regards, > Tomek > > -- > Tomek Rękawek | Adobe Research | www.adobe.com > reka...@adobe.com > >> On 29 Feb 2016, at 14:35, Chetan Mehrotra wrote: >> >> On Mon, Feb 29, 2016 at 6:42 PM, Tomek Rekawek wrote: >>> I wonder if we can switch the order of length and identity comparison in >>> AbstractBlob#equal() method. Is there any case in which the >>> getContentIdentity() method will be slower than length()? >> >> That can be switched but I am afraid that it would not work as >> expected. In JackrabbitNodeState#createBlob determining the >> contentIdentity involves determining the length. You can give >> org.apache.jackrabbit.oak.upgrade.blob.LengthCachingDataStore a try >> (See OAK-2882 for details) >> >> Chetan Mehrotra >
Re: [Blocked] Re: Oak 1.3.17/1.4.0 release plan
as far as I know Vikas is working on https://issues.apache.org/jira/browse/OAK-4066 and the fix should get pushed shortly. Regards, Tommaso Il giorno lun 29 feb 2016 alle ore 15:16 Davide Giannella ha scritto: > On 29/02/2016 12:24, Davide Giannella wrote: > > On 29/02/2016 10:22, Tommaso Teofili wrote: > >> and > >> > >> OAK-4039 > >> > > I followed up on https://issues.apache.org/jira/browse/OAK-4039. > > > > thanks for pointing it out both you and Marcel. It goes by its own that > > if the build is broken it wont be possible to release 1.4. > > > Team, the release is currently blocked. > > The build is broken by > > https://issues.apache.org/jira/browse/OAK-4039 > > Can anyone provide feedbacks here? I asked about a possible decision. > > and in any case we have two blocker issues as unresolved > > https://issues.apache.org/jira/browse/OAK-4012 > https://issues.apache.org/jira/browse/OAK-4066 > > Can I have feedback on all of them please? > > Cheers > Davide > > > > >
Re: testing blob equality
Thanks Chetan, I haven’t noticed the length() invocation in the createBlob(). It seems that the LengthCachingDataStore is something I was looking for. Best regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com > On 29 Feb 2016, at 14:35, Chetan Mehrotra wrote: > > On Mon, Feb 29, 2016 at 6:42 PM, Tomek Rekawek wrote: >> I wonder if we can switch the order of length and identity comparison in >> AbstractBlob#equal() method. Is there any case in which the >> getContentIdentity() method will be slower than length()? > > That can be switched but I am afraid that it would not work as > expected. In JackrabbitNodeState#createBlob determining the > contentIdentity involves determining the length. You can give > org.apache.jackrabbit.oak.upgrade.blob.LengthCachingDataStore a try > (See OAK-2882 for details) > > Chetan Mehrotra
[Blocked] Re: Oak 1.3.17/1.4.0 release plan
On 29/02/2016 12:24, Davide Giannella wrote: > On 29/02/2016 10:22, Tommaso Teofili wrote: >> and >> >> OAK-4039 >> > I followed up on https://issues.apache.org/jira/browse/OAK-4039. > > thanks for pointing it out both you and Marcel. It goes by its own that > if the build is broken it wont be possible to release 1.4. > Team, the release is currently blocked. The build is broken by https://issues.apache.org/jira/browse/OAK-4039 Can anyone provide feedbacks here? I asked about a possible decision. and in any case we have two blocker issues as unresolved https://issues.apache.org/jira/browse/OAK-4012 https://issues.apache.org/jira/browse/OAK-4066 Can I have feedback on all of them please? Cheers Davide
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
On 2016-02-29 11:05, Dominique Jaeggi wrote: ... [X] +1 Release this package as Apache Jackrabbit Oak 1.0.28 (tested with check script invocation change for 1.0.28) Best regards, Julian
Re: testing blob equality
On Mon, Feb 29, 2016 at 6:42 PM, Tomek Rekawek wrote: > I wonder if we can switch the order of length and identity comparison in > AbstractBlob#equal() method. Is there any case in which the > getContentIdentity() method will be slower than length()? That can be switched but I am afraid that it would not work as expected. In JackrabbitNodeState#createBlob determining the contentIdentity involves determining the length. You can give org.apache.jackrabbit.oak.upgrade.blob.LengthCachingDataStore a try (See OAK-2882 for details) Chetan Mehrotra
testing blob equality
Hello, one of our customers tries to perform a repeated upgrade [1], using a JCR2+S3 repository as a source. The repository is large and the migration process spends most of the time communicating with S3. It seems that besides from copying the new content, it gets the S3 metadata of each already migrated binary. The cause lies in the AbstractBlob#equal(Blob a, Blob b) method, which first compares the lengths of the binaries and then their identities. The S3DataStore gets the length from the remote service, so the equal() is quite slow. I wonder if we can switch the order of length and identity comparison in AbstractBlob#equal() method. Is there any case in which the getContentIdentity() method will be slower than length()? Best regards, Tomek [1] https://issues.apache.org/jira/browse/OAK-2619 -- Tomek Rękawek | Adobe Research | www.adobe.com reka...@adobe.com
Re: Oak 1.3.17/1.4.0 release plan
On 29/02/2016 10:22, Tommaso Teofili wrote: > and > > OAK-4039 > I followed up on https://issues.apache.org/jira/browse/OAK-4039. thanks for pointing it out both you and Marcel. It goes by its own that if the build is broken it wont be possible to release 1.4. Cheers Davide
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
On Mon, Feb 29, 2016 at 12:08 PM, Alex Parvulescu wrote: > would that be 1.0.28 instead of 1.0.27? > (sh check-release.sh oak 1.0.28 906717610585d6be9cb2abc6814083cd87ad2a3e) yes indeed. i apologize for the copy paste error!
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
[X] +1 Release this package as Apache Jackrabbit Oak 1.0.28 On Mon, Feb 29, 2016 at 11:05 AM, Dominique Jaeggi wrote: > A candidate for the Jackrabbit Oak 1.0.28 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.28/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.28/ > > The SHA1 checksum of the archive is > 906717610585d6be9cb2abc6814083cd87ad2a3e. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh oak 1.0.27 > 906717610585d6be9cb2abc6814083cd87ad2a3e > > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.28. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.28 > > [ ] -1 Do not release this package because... > > My vote is +1. > > Thanks > dom. >
Re: Oak 1.3.17/1.4.0 release plan
I've fixed OAK-4068 related error (in IndexDefinitionTest). Regards, Tommaso Il giorno lun 29 feb 2016 alle ore 11:22 Tommaso Teofili < tommaso.teof...@gmail.com> ha scritto: > and > > OAK-4039 > > Il giorno lun 29 feb 2016 alle ore 11:10 Marcel Reutegger < > mreut...@adobe.com> ha scritto: > >> trunk is currently broken. see: >> >> https://issues.apache.org/jira/browse/OAK-4068 >> >> >> regards >> marcel >> >> On 29/02/16 10:41, "Davide Giannella" wrote: >> >> >Team, a quick update on the release plan. >> > >> >At 11am GMT it will be the 72hrs of the jackrabbit 2.12.1 release >> >pending votes. I will release, assuming we have votes, and include it in >> >the oak trunk *before* branching. >> > >> >This means that I will branch 1.4 more or less around 2pm GMT. >> > >> >Any concern reply here or ping me over chat. >> > >> >Cheers >> >Davide >> >>
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
On 29/02/16 11:05, "Dominique Jaeggi" wrote: >Please vote on releasing this package as Apache Jackrabbit Oak 1.0.28. >The vote is open for the next 72 hours and passes if a majority of at >least three +1 Jackrabbit PMC votes are cast. All checks OK, running the script for *1.0.28*. +1 Release this package as Apache Jackrabbit Oak 1.0.28 Regards Marcel
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
On Mon, Feb 29, 2016 at 3:35 PM, Dominique Jaeggi wrote: > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.28. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > +1 Release this package as Apache Jackrabbit Oak 1.0.28 (sh check-release.sh oak 1.0.28 906717610585d6be9cb2abc6814083cd87ad2a3e) Thanks Amit
Re: [VOTE] Release Apache Jackrabbit Oak 1.0.28
Hi, would that be 1.0.28 instead of 1.0.27? (sh check-release.sh oak 1.0.28 906717610585d6be9cb2abc6814083cd87ad2a3e) I'm running the check now, alex On Mon, Feb 29, 2016 at 11:05 AM, Dominique Jaeggi wrote: > A candidate for the Jackrabbit Oak 1.0.28 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.28/ > > The release candidate is a zip archive of the sources in: > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.28/ > > The SHA1 checksum of the archive is > 906717610585d6be9cb2abc6814083cd87ad2a3e. > > A staged Maven repository is available for review at: > > https://repository.apache.org/ > > The command for running automated checks against this release candidate is: > > $ sh check-release.sh oak 1.0.27 > 906717610585d6be9cb2abc6814083cd87ad2a3e > > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.28. > The vote is open for the next 72 hours and passes if a majority of at > least three +1 Jackrabbit PMC votes are cast. > > [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.28 > > [ ] -1 Do not release this package because... > > My vote is +1. > > Thanks > dom. >
Re: R: info on queries and index
On 26/02/2016 10:17, Ancona Francesco wrote: > Hello, > so if Lucene or Solr have a problem or are busy for some reasons, we can't > search anything, if i understand. As already pointed out out by Michael, other that you plan to leverage Solr specific features I would stick to lucene. The query engine is able to serve queries while it indexs or re-indexes so you should not have failures on such side. Of course by the fact that Lucene, for example, is asynchronous the information returned by it may be slightly out do date as the new updates were not being processed already. > So, i imagine, we have to be very careful to the search engine that is a > potential single point of failure if it goes down or if loose index and so it > has to make a full reindex. Not familiar with the Solr side. But I guess that yes, if the Solr server goes down it will be not able to serve queries. With all the other approaches indexes are embedded in the product (oak-core) so if it's not available then something major has happened. If you miss an index definition; it means someone deleted it and it's a different things. > What kind of topology (application and search engine) do you suggest to > mitigate this problem ? As already said, other than you plan to deliver any Solr specific feature I would stick initially with Lucene. If you have to leverage solr I would go with usual approach for balancing and multiple solr servers for resilience. Davide
Re: Oak 1.3.17/1.4.0 release plan
and OAK-4039 Il giorno lun 29 feb 2016 alle ore 11:10 Marcel Reutegger < mreut...@adobe.com> ha scritto: > trunk is currently broken. see: > > https://issues.apache.org/jira/browse/OAK-4068 > > > regards > marcel > > On 29/02/16 10:41, "Davide Giannella" wrote: > > >Team, a quick update on the release plan. > > > >At 11am GMT it will be the 72hrs of the jackrabbit 2.12.1 release > >pending votes. I will release, assuming we have votes, and include it in > >the oak trunk *before* branching. > > > >This means that I will branch 1.4 more or less around 2pm GMT. > > > >Any concern reply here or ping me over chat. > > > >Cheers > >Davide > >
Re: Oak 1.3.17/1.4.0 release plan
trunk is currently broken. see: https://issues.apache.org/jira/browse/OAK-4068 regards marcel On 29/02/16 10:41, "Davide Giannella" wrote: >Team, a quick update on the release plan. > >At 11am GMT it will be the 72hrs of the jackrabbit 2.12.1 release >pending votes. I will release, assuming we have votes, and include it in >the oak trunk *before* branching. > >This means that I will branch 1.4 more or less around 2pm GMT. > >Any concern reply here or ping me over chat. > >Cheers >Davide
[VOTE] Release Apache Jackrabbit Oak 1.0.28
A candidate for the Jackrabbit Oak 1.0.28 release is available at: https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.28/ The release candidate is a zip archive of the sources in: https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.28/ The SHA1 checksum of the archive is 906717610585d6be9cb2abc6814083cd87ad2a3e. A staged Maven repository is available for review at: https://repository.apache.org/ The command for running automated checks against this release candidate is: $ sh check-release.sh oak 1.0.27 906717610585d6be9cb2abc6814083cd87ad2a3e Please vote on releasing this package as Apache Jackrabbit Oak 1.0.28. The vote is open for the next 72 hours and passes if a majority of at least three +1 Jackrabbit PMC votes are cast. [ ] +1 Release this package as Apache Jackrabbit Oak 1.0.28 [ ] -1 Do not release this package because... My vote is +1. Thanks dom.
Re: Oak 1.3.17/1.4.0 release plan
Team, a quick update on the release plan. At 11am GMT it will be the 72hrs of the jackrabbit 2.12.1 release pending votes. I will release, assuming we have votes, and include it in the oak trunk *before* branching. This means that I will branch 1.4 more or less around 2pm GMT. Any concern reply here or ping me over chat. Cheers Davide
