Re: OAK-7203 - Where should MountInfoProviderService reside?

[Robert Munteanu]

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?

[Alex Deparvu]

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  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?

[Robert Munteanu]

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

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

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #1242)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1242/ to 
view the results.

Changes:
[tomekr] OAK-6921: Support pluggable segment storage

 

Test results:
All tests passed

Re: OAK-7203 - Where should MountInfoProviderService reside?

[Oliver Lietz]

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?

[Oliver Lietz]

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

OAK-7203 - Where should MountInfoProviderService reside?

[Robert Munteanu]

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

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

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #1244)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1244/ to 
view the results.

Changes:
[reschke] fix svn:eol-style

 

Test results:
All tests passed

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.20

[Manfred Baedke]

[X] +1 Release this package as Apache Jackrabbit Oak 1.4.20


where

[INFO] Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 
2015-11-10T17:41:47+01:00)
[INFO] OS name: "windows 8.1", version: "6.3", arch: "amd64", family: 
"windows"

[INFO] Java version: 1.7.0_79, vendor: Oracle Corporation


Best regards,
Manfred

[VOTE] Release Apache Jackrabbit Oak 1.4.20

[Manfred Baedke]

A candidate for the Jackrabbit Oak 1.4.20 release is available at:

https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.20/

The release candidate is a zip archive of the sources in:


https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.20/

The SHA1 checksum of the archive is
538a7f10b93698ffd716b58e69606be0e85e1516.

A staged Maven repository is available for review at:

https://repository.apache.org/

The command for running automated checks against this release candidate is:

$ sh check-release.sh oak 1.4.20
538a7f10b93698ffd716b58e69606be0e85e1516

Please vote on releasing this package as Apache Jackrabbit Oak 1.4.20.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.

[ ] +1 Release this package as Apache Jackrabbit Oak 1.4.20
[ ] -1 Do not release this package because...

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.20

[Julian Reschke]

On 2018-02-13 16:13, Manfred Baedke wrote:

...


[X] +1 Release this package as Apache Jackrabbit Oak 1.4.20

...where...


[INFO] Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d; 
2017-10-18T09:58:13+02:00)
[INFO] OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Java version: 1.8.0_162, vendor: Oracle Corporation



Best regards, Julian

Re: OAK-7203 - Where should MountInfoProviderService reside?

[Robert Munteanu]

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

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

[Apache Jenkins Server]

The Apache Jenkins build system has built Jackrabbit Oak (build #1243)

Status: Still Failing

Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/1243/ to 
view the results.

Changes:
[rombert] Improve the composite node store documentation a bit

 

Test results:
All tests passed

Re: OAK-7203 - Where should MountInfoProviderService reside?

[Robert Munteanu]

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 
> 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?

[Oliver Lietz]

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  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