Module to host oak-run console scripts

Hi Team, We have few oak-run console groovy scripts used often to analyze/troubleshoot customer setups. Currently these are scattered across various github gist. I propose that we 1. Create a new module oak-run-scripts (or oak-console-scripts) and host such generic scripts there. 2. This module

Re: possible to graft a remote non-JCR source to a path?

hi david, long-time AEM developer here. i wouldn't recommend grafting at oak level even if it was possible. the resource API of sling is loose and amenable to all sorts of datatypes. and since your main point of interaction is through sling/AEM, that would be the easiest to build out and

Re: [m12] Effort to Improve Modularisation of Oak

Hi Michael I try to describe the changes proposed by the PoC in https://issues.apache.org/jira/browse/OAK-6073?focusedCommentId=15965623 ge=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment -15965623. Additionally added some step-by-step instruction on how we proceeded.

RE: possible to graft a remote non-JCR source to a path?

Thanks Roy, yes that's the other suggestion Adobe had identified and we're looking at it as well. In your opinion is integration of DAM Assets at the JCR level with Oak just a bad idea even if it is possible? From: Roy Teeuwen [mailto:r...@teeuwen.be] Sent: Wednesday, April 12, 2017 11:22 AM

Re: possible to graft a remote non-JCR source to a path?

Hey David, Seeing as you are using AEM, thus Sling, have you looked at the ResourceProvider interface? With this you can bind resources coming from another place than the JCR repo to the content tree. You can look at these examples, the first one fetches content from a couchbase, the second

possible to graft a remote non-JCR source to a path?

Greetings, We are researching the best way to expose digital assets that are managed in a non-JCR based enterprise DAM system via Adobe's native DAM UI and are wondering if it's possible to, for example, bind a path like /content/dam/edam/... to a remote data source. Adobe had released an

Re: Backport of OAK-4933 to 1.6

On 12.04.17 09:17, Marcel Reutegger wrote: Hi, On 28/03/17 09:09, Michael Dürig wrote: As Marcel mentions on the issue a better approach would be to release this independently. If this is blocked by dependencies we should make an effort to sort this out, as now is the time in the release

Re: [m12] Effort to Improve Modularisation of Oak

Hi Angela, Thanks for driving this and coming up with a PoC. I like the direction this is taking. The module boundaries make sense to me and having certain dependencies de-tangled will certainly be helpful going forward. Could you share a bit of your experience doing this refactoring? What

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.25

[X] +1 Release this package as Apache Jackrabbit Oak 1.2.25 alex On Tue, Apr 11, 2017 at 7:51 AM, Amit Jain wrote: > A candidate for the Jackrabbit Oak 1.2.25 release is available at: > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.2.25/ > > The release

[m12] Effort to Improve Modularisation of Oak

Hi As mentioned my Marcel this morning [0] we had some offline discussions related to the oak-blob-azure module and how we could independently release it. While we didn't see a satisfying solution for the 1.6 branch, we concluded that we should pick up the modularisation discussion for address

Re: Backport of OAK-4933 to 1.6

Hi Marcel Thanks for the summary. From my understanding the proposal additionally included the wish that we move forward with the modularisation and aims for independent releases for the oak-blob-azure module in trunk. See OAK-6069 [0] and subtask OAK-6073 [1] for the corresponding JIRA issue

Re: Backport of OAK-4933 to 1.6

Hi, On 28/03/17 09:09, Michael Dürig wrote: As Marcel mentions on the issue a better approach would be to release this independently. If this is blocked by dependencies we should make an effort to sort this out, as now is the time in the release cycle for doing so. So for now -1 from my side