You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Robert Munteanu <ro...@apache.org> on 2018/02/13 10:03:34 UTC
OAK-7203 - Where should MountInfoProviderService reside?
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 we have to add oak-store-composite.
There are two options here:
1. Move the service to oak-core.
2. Require oak-store-composite for deployments
If we go with 1, we have simpler deployments ( one less bundle ). If we
go with 2, we split the logic from the oak-store-composite bundle and
add more stuff on top of oak-core.
Thoughts?
Thanks,
Robert
[1]: https://issues.apache.org/jira/browse/OAK-7203
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Alex Deparvu <st...@apache.org>.
To wrap this up, I plan on closing OAK-7203 as won't fix.
I agree with the idea that the code itself should work without that
dependency, however the added complexity of having that reference dynamic
(over system restarts, not over a single run) it simply not worth the
trouble. The downside is obviously having to add another bundle to the
deployment list, and the docs should of course reflect this.
thanks,
alex
On Tue, Feb 13, 2018 at 3:47 PM, Robert Munteanu <ro...@apache.org> wrote:
> On Tue, 2018-02-13 at 15:29 +0100, Oliver Lietz wrote:
> > On Tuesday 13 February 2018 14:37:29 Alex Deparvu wrote:
> > > Hi,
> >
> > Hi,
> >
> > > I would not move it to oak-core, it would be (I think) a step in
> > > the wrong
> > > direction wrt. the modularization effort.
> >
> > seriously, which direction is it? oak-core now depends on oak-store-
> > composite
> > (which provides optional features) and oak-lucene depends on oak-
> > store-
> > document which is otherwise not required when running Oak with
> > Segment Tar
> > store. What's the point of this m12n effort?
>
> oak-lucene depending on oak-store-document is not a very good thing
> IMO, looks wrong. But that's an implementation problem, not a design
> fault in modularizing Pak. Filed [1] for it.
>
> The reasoning behind this is documented in OAK-6069 - Modularisation of
> Oak [2], and the main driver is stop releasing all modules at a time.
> For instance, a bugfix in oak-store-segment should not require
> _everything_ to be released.
>
> [1]: https://issues.apache.org/jira/browse/OAK-7263
> [2]: https://issues.apache.org/jira/browse/OAK-6069
>
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2018-02-13 at 15:29 +0100, Oliver Lietz wrote:
> On Tuesday 13 February 2018 14:37:29 Alex Deparvu wrote:
> > Hi,
>
> Hi,
>
> > I would not move it to oak-core, it would be (I think) a step in
> > the wrong
> > direction wrt. the modularization effort.
>
> seriously, which direction is it? oak-core now depends on oak-store-
> composite
> (which provides optional features) and oak-lucene depends on oak-
> store-
> document which is otherwise not required when running Oak with
> Segment Tar
> store. What's the point of this m12n effort?
oak-lucene depending on oak-store-document is not a very good thing
IMO, looks wrong. But that's an implementation problem, not a design
fault in modularizing Pak. Filed [1] for it.
The reasoning behind this is documented in OAK-6069 - Modularisation of
Oak [2], and the main driver is stop releasing all modules at a time.
For instance, a bugfix in oak-store-segment should not require
_everything_ to be released.
[1]: https://issues.apache.org/jira/browse/OAK-7263
[2]: https://issues.apache.org/jira/browse/OAK-6069
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Tuesday 13 February 2018 14:37:29 Alex Deparvu wrote:
> Hi,
Hi,
> I would not move it to oak-core, it would be (I think) a step in the wrong
> direction wrt. the modularization effort.
seriously, which direction is it? oak-core now depends on oak-store-composite
(which provides optional features) and oak-lucene depends on oak-store-
document which is otherwise not required when running Oak with Segment Tar
store. What's the point of this m12n effort?
Regards,
O.
> Re. OAK-7203, I think we should make that specific dependency optional, but
> I'm not convinced you won't have another bundle pulling in the composite
> dependency anyway.
>
>
> best,
> alex
>
> On Tue, Feb 13, 2018 at 1:46 PM, Robert Munteanu <ro...@apache.org> wrote:
> > On Tue, 2018-02-13 at 13:04 +0100, Oliver Lietz wrote:
> > > 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 have simpler deployments ( one less bundle
> > > > > > ).
> > > > > > If we
> > > > > > go with 2, we split the logic from the oak-store-composite
> > > > > > bundle
> > > > > > and
> > > > > > add more stuff on top of oak-core.
> > > > >
> > > > > 1 means simpler deployment and more stuff in oak-core, but the
> > > > > MountInfoProvider is required for composite and non-composite
> > > > > stores.
> > > > > Having it in (experimental) module oak-store-composite feels
> > > > > strange.
> > > >
> > > > Why do you consider oak-store-composite experimental? It's not
> > > > documented very well unfortunately, but it's as well-tested as any
> > > > other component in Oak from my point of view.
> > >
> > > AFAIR Oak's documentation says it's "experimental". The composite ns
> > > page says
> > > it's work-in-progress – outdated documentation?
> >
> > That's a good point. I've updated the docs to remove the information
> > about the compositens being work-in-progress, just the documentation is
> >
> > :-)
> >
> > Robert
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2018-02-13 at 14:37 +0100, Alex Deparvu wrote:
> Hi,
>
> I would not move it to oak-core, it would be (I think) a step in the
> wrong
> direction wrt. the modularization effort.
>
> Re. OAK-7203, I think we should make that specific dependency
> optional, but
> I'm not convinced you won't have another bundle pulling in the
> composite
> dependency anyway.
Making the dependency optional would complicate the component. There
are a number of components that perform initialization work and depend
on the MountInfoProvider to know whether they should write data in a
composite-friendly setup. AN example are the index-related classes.
Initialising those without a MountInfoProvider or with a 'default'
MountInfoProvider opens up the door to data being incorrectly handled
for a short window of time.
I think we should keep the dependency required.
Thanks,
Robert
>
>
> best,
> alex
>
>
>
>
> On Tue, Feb 13, 2018 at 1:46 PM, Robert Munteanu <ro...@apache.org>
> wrote:
>
> > On Tue, 2018-02-13 at 13:04 +0100, Oliver Lietz wrote:
> > > 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 have simpler deployments ( one less
> > > > > > bundle
> > > > > > ).
> > > > > > If we
> > > > > > go with 2, we split the logic from the oak-store-composite
> > > > > > bundle
> > > > > > and
> > > > > > add more stuff on top of oak-core.
> > > > >
> > > > > 1 means simpler deployment and more stuff in oak-core, but
> > > > > the
> > > > > MountInfoProvider is required for composite and non-composite
> > > > > stores.
> > > > > Having it in (experimental) module oak-store-composite feels
> > > > > strange.
> > > >
> > > > Why do you consider oak-store-composite experimental? It's not
> > > > documented very well unfortunately, but it's as well-tested as
> > > > any
> > > > other component in Oak from my point of view.
> > >
> > > AFAIR Oak's documentation says it's "experimental". The composite
> > > ns
> > > page says
> > > it's work-in-progress – outdated documentation?
> >
> > That's a good point. I've updated the docs to remove the
> > information
> > about the compositens being work-in-progress, just the
> > documentation is
> > :-)
> >
> > Robert
> >
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Alex Deparvu <st...@apache.org>.
Hi,
I would not move it to oak-core, it would be (I think) a step in the wrong
direction wrt. the modularization effort.
Re. OAK-7203, I think we should make that specific dependency optional, but
I'm not convinced you won't have another bundle pulling in the composite
dependency anyway.
best,
alex
On Tue, Feb 13, 2018 at 1:46 PM, Robert Munteanu <ro...@apache.org> wrote:
> On Tue, 2018-02-13 at 13:04 +0100, Oliver Lietz wrote:
> > 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 have simpler deployments ( one less bundle
> > > > > ).
> > > > > If we
> > > > > go with 2, we split the logic from the oak-store-composite
> > > > > bundle
> > > > > and
> > > > > add more stuff on top of oak-core.
> > > >
> > > > 1 means simpler deployment and more stuff in oak-core, but the
> > > > MountInfoProvider is required for composite and non-composite
> > > > stores.
> > > > Having it in (experimental) module oak-store-composite feels
> > > > strange.
> > >
> > > Why do you consider oak-store-composite experimental? It's not
> > > documented very well unfortunately, but it's as well-tested as any
> > > other component in Oak from my point of view.
> >
> > AFAIR Oak's documentation says it's "experimental". The composite ns
> > page says
> > it's work-in-progress – outdated documentation?
>
> That's a good point. I've updated the docs to remove the information
> about the compositens being work-in-progress, just the documentation is
> :-)
>
> Robert
>
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Robert Munteanu <ro...@apache.org>.
On Tue, 2018-02-13 at 13:04 +0100, Oliver Lietz wrote:
> 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 have simpler deployments ( one less bundle
> > > > ).
> > > > If we
> > > > go with 2, we split the logic from the oak-store-composite
> > > > bundle
> > > > and
> > > > add more stuff on top of oak-core.
> > >
> > > 1 means simpler deployment and more stuff in oak-core, but the
> > > MountInfoProvider is required for composite and non-composite
> > > stores.
> > > Having it in (experimental) module oak-store-composite feels
> > > strange.
> >
> > Why do you consider oak-store-composite experimental? It's not
> > documented very well unfortunately, but it's as well-tested as any
> > other component in Oak from my point of view.
>
> AFAIR Oak's documentation says it's "experimental". The composite ns
> page says
> it's work-in-progress – outdated documentation?
That's a good point. I've updated the docs to remove the information
about the compositens being work-in-progress, just the documentation is
:-)
Robert
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 have simpler deployments ( one less bundle ).
> > > If we
> > > go with 2, we split the logic from the oak-store-composite bundle
> > > and
> > > add more stuff on top of oak-core.
> >
> > 1 means simpler deployment and more stuff in oak-core, but the
> > MountInfoProvider is required for composite and non-composite stores.
> > Having it in (experimental) module oak-store-composite feels strange.
>
> Why do you consider oak-store-composite experimental? It's not
> documented very well unfortunately, but it's as well-tested as any
> other component in Oak from my point of view.
AFAIR Oak's documentation says it's "experimental". The composite ns page says
it's work-in-progress – outdated documentation?
O.
> Robert
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Robert Munteanu <ro...@apache.org>.
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 have simpler deployments ( one less bundle ).
> > If we
> > go with 2, we split the logic from the oak-store-composite bundle
> > and
> > add more stuff on top of oak-core.
>
> 1 means simpler deployment and more stuff in oak-core, but the
> MountInfoProvider is required for composite and non-composite stores.
> Having it in (experimental) module oak-store-composite feels strange.
Why do you consider oak-store-composite experimental? It's not
documented very well unfortunately, but it's as well-tested as any
other component in Oak from my point of view.
Robert
Re: OAK-7203 - Where should MountInfoProviderService reside?
Posted by Oliver Lietz <ap...@oliverlietz.de>.
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 we have to add oak-store-composite.
>
> There are two options here:
>
> 1. Move the service to oak-core.
> 2. Require oak-store-composite for deployments
>
> If we go with 1, we have simpler deployments ( one less bundle ). If we
> go with 2, we split the logic from the oak-store-composite bundle and
> add more stuff on top of oak-core.
1 means simpler deployment and more stuff in oak-core, but the
MountInfoProvider is required for composite and non-composite stores.
Having it in (experimental) module oak-store-composite feels strange.
Regards,
O.
> Thoughts?
>
> Thanks,
>
> Robert
>
>
> [1]: https://issues.apache.org/jira/browse/OAK-7203