hi,
I'm looking for info how to use Oak in a revision-/audit-proof manner to
archive versioned assets in a (read-only) repo. The only related document I've
found so far is the talk "Binary Data Management Features in Oak 1.8" from
Matt and Conrad. Any other sources or ideas?
Thanks,
O.
't have another bundle pulling in the composite
> dependency anyway.
>
>
> best,
> alex
>
> On Tue, Feb 13, 2018 at 1:46 PM, Robert Munteanu <romb...@apache.org> wrote:
> > On Tue, 2018-02-13 at 13:04 +0100, Oliver Lietz wrote:
> > > On Tuesday 13 Feb
On Tuesday 13 February 2018 13:10:23 Robert Munteanu wrote:
> On Tue, 2018-02-13 at 11:51 +0100, Oliver Lietz wrote:
> > > 1. Move the service to oak-core.
> > > 2. Require oak-store-composite for deployments
> > >
> > > If we go with 1, we hav
On Tuesday 13 February 2018 12:03:34 Robert Munteanu wrote:
> Hi,
Hi,
> In OAK-7203 [1] we're discussing the best location for the
> MountInfoProviderService. The context is that due to the addition of
> the mounts concept a MountInfoProvider implementation is required and
> for OSGi deployment
On Wednesday 01 February 2017 19:20:05 Julian Reschke wrote:
> On 2017-02-01 16:48, Julian Reschke wrote:
> > ...
>
> That mail was intended for a different mailing list. Sorry.
Forwared to d...@sling.apache.org. Thanks, Julian.
Regards,
O.
> Best regards, Julian
understand your mail correctly, you gave a -1 to every proposed
> >> option. Can you be a little bit more constructive about your approach, or
> >> explain the message that is evidently hidden in your email?
> >>
> >> Regards,
> >>
> >> Francesco
On Monday 25 April 2016 16:46:45 Michael Dürig wrote:
> Hi,
>
> There is a couple of names that came up in the discussion [1]:
>
> oak-local-store
> oak-segment-file
> oak-embedded-store
> oak-segment-store
> oak-segment-tar
> oak-segment-next
>
> Please vote which of the above six options you
On Wednesday 09 March 2016 08:07:30 Marcel Reutegger wrote:
> Hi Dominik,
hi,
> an Oak cluster on MongoDB does not provide strong
> consistency guarantees. The same is actually true for
> all DocumentNodeStore cluster setups, independent of the
> DocumentStore backend. A write on one cluster
hi,
can someone please take care of OAK-3503 for 1.3.9? The Require-Capability
header (OAK-3083) prevents a successful deployment on Karaf and this is a
really trivial fix.
Thanks,
O.