Re: upgrade repository structure with backward-incompatible changes

Hi Marco In this case I think you should use the JCR API to implement your content changes. I am not aware of a pure JCR toolkit that helps with this, so you may just need to write something yourself. Regards Julian On Fri, May 19, 2017 at 5:00 PM, Marco Piovesana

Re: upgrade repository structure with backward-incompatible changes

Hi Julian, I meant I'm using Oak not Sing. Yes I'm using JCR API. Marco. On Fri, May 19, 2017 at 2:22 PM, Julian Sedding wrote: > Hi Marco > > On Fri, May 19, 2017 at 2:10 PM, Marco Piovesana > wrote: > > Hi Julian, Michael and Robert > > first of all

BUILD FAILURE: Jackrabbit Oak - Build # 317 - Failure

The Apache Jenkins build system has built Jackrabbit Oak (build #317) Status: Failure Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/317/ to view the results. Changes: [chetanm] OAK-6243 - Refactor directory construction logic via DirectoryFactory Enable passing in a

Re: upgrade repository structure with backward-incompatible changes

Hi Marco On Fri, May 19, 2017 at 2:10 PM, Marco Piovesana wrote: > Hi Julian, Michael and Robert > first of all thanks for the suggestions. > I'm using Oak directly inside my application, Do you mean you are not using the JCR API? > so I guess the Sling Pipes > are not

Re: upgrade repository structure with backward-incompatible changes

Hi Julian, Michael and Robert first of all thanks for the suggestions. I'm using Oak directly inside my application, so I guess the Sling Pipes are not something I can use, or not? Is the concept of Pipe already defined in some way inside oak? Marco. On Fri, May 19, 2017 at 10:39 AM, Julian

[jira] [Updated] (JCRVLT-177) jcr:content and its children not overwritten during installation of Simple File Aggregate

[ https://issues.apache.org/jira/browse/JCRVLT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-177: --- Summary: jcr:content and its children not overwritten during installation of Simple File

[jira] [Updated] (JCRVLT-177) jcr:content child node for Simple File Aggregates not overwritten

[ https://issues.apache.org/jira/browse/JCRVLT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-177: --- Description: For simple file aggregates in a package, the child node {{jcr:content}} is not

[jira] [Updated] (JCRVLT-177) jcr:content child node for Simple File Aggregates not overwritten

[ https://issues.apache.org/jira/browse/JCRVLT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-177: --- Description: For simple file aggregates in a package, the child node {{jcr:content}} is not

[jira] [Updated] (JCRVLT-177) jcr:content child node for Simple File Aggregates not overwritten

[ https://issues.apache.org/jira/browse/JCRVLT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-177: --- Description: For simple file aggregates in a package, the child node {{jcr:content}} is not

[jira] [Updated] (JCRVLT-177) jcr:content child node for Simple File Aggregates not overwritten

[ https://issues.apache.org/jira/browse/JCRVLT-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konrad Windszus updated JCRVLT-177: --- Description: For simple file aggregates in a package, the child node {{jcr:content}} is not

[jira] [Created] (JCRVLT-177) jcr:content child node for Simple File Aggregates not overwritten

Konrad Windszus created JCRVLT-177: -- Summary: jcr:content child node for Simple File Aggregates not overwritten Key: JCRVLT-177 URL: https://issues.apache.org/jira/browse/JCRVLT-177 Project:

Intent to backport to 1.4: OAK-4867

This is in 1.6 and is a prerequisite for further backports...

Re: upgrade repository structure with backward-incompatible changes

Hi Marco It sounds like you are dealing with a JCR-based application and thus you should be using the JCR API (directly or indirectly, e.g. via Sling) to change your content. CommitHook is an Oak internal API that does not enforce any JCR semantics. So if you were to go down that route, you

BUILD FAILURE: Jackrabbit Oak - Build # 315 - Still Failing

The Apache Jenkins build system has built Jackrabbit Oak (build #315) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/315/ to view the results. Changes: No changes Test results: No tests ran.

[jira] [Commented] (JCRVLT-50) Add support for "hollow" packages

[ https://issues.apache.org/jira/browse/JCRVLT-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017053#comment-16017053 ] Tobias Bocanegra commented on JCRVLT-50: WIP:

[jira] [Assigned] (JCRVLT-50) Add support for "hollow" packages

[ https://issues.apache.org/jira/browse/JCRVLT-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tobias Bocanegra reassigned JCRVLT-50: -- Assignee: Tobias Bocanegra > Add support for "hollow" packages >

BUILD FAILURE: Jackrabbit Oak - Build # 314 - Failure

The Apache Jenkins build system has built Jackrabbit Oak (build #314) Status: Failure Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/314/ to view the results. Changes: No changes Test results: No tests ran.

Re: Oak 1.7.0 release plan

Hi Davide, The issue is marked as a blocker to save you the trouble of finding out very late that the javadocs plugin will crash the release, otherwise it has zero impact on the actual code to be released. There is a patch attached with a proposal for updating the javadocs, to which no one

Re: Intent to backport to 1.6 and 1.4: OAK-5741

On 2017-05-19 09:13, Julian Reschke wrote: On 2017-05-19 08:16, Chetan Mehrotra wrote: On Thu, May 18, 2017 at 5:51 PM, Julian Reschke wrote: (needed for a subsequent backport of OAK-5704) Probably we should wait for OAK-5704 for sometime after 1.7.0 is cut and that

Oak 1.7.0 release plan

Hello team, I'm planning to cut Oak on Monday 22nd May. If there are any objections please let me know. Otherwise I will re-schedule any non-resolved issue for the next iteration. There's currently one blocker: https://issues.apache.org/jira/browse/OAK-6150. I will give it a deeper look on

Re: Intent to backport to 1.6 and 1.4: OAK-5741

On 2017-05-19 08:16, Chetan Mehrotra wrote: On Thu, May 18, 2017 at 5:51 PM, Julian Reschke wrote: (needed for a subsequent backport of OAK-5704) Probably we should wait for OAK-5704 for sometime after 1.7.0 is cut and that build is subjected some longevity testing

Re: Intent to backport to 1.6 and 1.4: OAK-5571

As mentioned in previous mail can we wait for 1.7.0 release such that all new changes in RevisionGC get some longevity testing. And after that we do the backports. Chetan Mehrotra On Fri, May 19, 2017 at 12:29 PM, Julian Reschke wrote: >

Intent to backport to 1.6 and 1.4: OAK-5571

https://issues.apache.org/jira/browse/OAK-5571

Re: Intent to backport to 1.6 and 1.4: OAK-5741

On Thu, May 18, 2017 at 5:51 PM, Julian Reschke wrote: > (needed for a subsequent backport of OAK-5704) Probably we should wait for OAK-5704 for sometime after 1.7.0 is cut and that build is subjected some longevity testing before backporting it to branched Chetan