Re: [m12] Effort to Improve Modularisation of Oak

Great work so far to everyone involved in this effort. I'm under the impression that this refactoring will constitute a change in the public API contract of Oak. In reading the links it seems to hint at this but whether or not this will actually result in a public API change isn't explicitly

BUILD FAILURE: Jackrabbit Oak - Build # 158 - Failure

The Apache Jenkins build system has built Jackrabbit Oak (build #158) Status: Failure Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/158/ to view the results. Changes: [angela] OAK-6078 : oak.util.ApproximateCounter must have private constructor [mreutegg] OAK-3342:

Re: [m12] Effort to Improve Modularisation of Oak

Hi Michael and Oak-Devs Just a quick update: I added more details to OAK-6073 included a summary of the effects on oak-core and oak-commons as well as listing changes to non-test dependencies of most modules. I would like to encourage you to look at the fork and the summary and provide feedback

Re: [m12] Effort to Improve Modularisation of Oak

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. Thanks,

Re: Module to host oak-run console scripts

On Thu, Apr 13, 2017 at 3:29 PM, Robert Munteanu wrote: > Or we can even have a 'contrib' > area in the top-level oak directory and place the scripts there, i.e. > /contrib/scripts or /contrib/oak-run-scripts That looks like a viable option. I can keep them in a module my

Re: Module to host oak-run console scripts

Hi, On 13.04.17 11:33, Chetan Mehrotra wrote: Major benefit of scripts are they are faster to implement and can be used in older branches without impacting runtime. I agree on this part. But most of this benefit comes from not providing the same level of maintenance, testing, compatibility

Re: Module to host oak-run console scripts

On Thu, 2017-04-13 at 15:03 +0530, Chetan Mehrotra wrote: > On Thu, Apr 13, 2017 at 2:51 PM, Marcel Reutegger > wrote: > > one concern I have is maintainability. Scripts tend to go out of > > date and my > > question would be how we can detect this when it happens. > > Yes

Re: Module to host oak-run console scripts

On Thu, Apr 13, 2017 at 2:51 PM, Marcel Reutegger wrote: > one concern I have is maintainability. Scripts tend to go out of date and my > question would be how we can detect this when it happens. Yes that would be the case. The scripts come with lesser testing and can go

Re: Module to host oak-run console scripts

Hi, one concern I have is maintainability. Scripts tend to go out of date and my question would be how we can detect this when it happens. As for the example with the index consistency check you mentioned, I'm wondering why this is implemented as a script instead of plain Java. I'd say if we

Re: Module to host oak-run console scripts

See OAK-6075 for an example for such a script Chetan Mehrotra On Thu, Apr 13, 2017 at 10:35 AM, Chetan Mehrotra wrote: > Hi Team, > > We have few oak-run console groovy scripts used often to > analyze/troubleshoot customer setups. Currently these are scattered >

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

Hi, On Wed, 2017-04-12 at 15:31 +, Beaudet, David wrote: > 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? With the