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

[Apache Jenkins Server]

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

Status: Still Failing

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

Changes:
No changes
 

Test results:
No tests ran.

Re: Oak Bundle versioning.

[Davide Giannella]

On 06/10/2017 15:16, Robert Munteanu wrote:
> Yeat another one can be embedding Oak in their project via
> Maven/Gradle/etc dependencies . This is currently done in the oak-
> examples module. Here we can consider defining an 'uber-pom' that is
> used to pull in dependencies of a given Oak release.

This in my option is the only way we currently have Oak consumed by
third parties. Even when we speak about the OSGi/Sling case, eventually
it's a Maven dependency that gets either embedded (jackrabbit) in the
bundle or referenced in an OSGi container.

I don't really see the need of a quickstart. Probably one of the things
we should start achieving from this discussion is:

what do we want to have? I see independent module release with their own
versioning.

Do we, as community want to get there?

Then, once we agree whether we want to get there or not, we can start
looking at different projects that already do so, for instance Sling and
see if such method would fit us. Eventually starting to highlight any
problems we may have: backports and branching to mention a few.

For all this last points I guess a wiki page would be a good place where
to put all the ideas together.

Davide

BUILD FAILURE: Jackrabbit Oak - Build # 844 - Failure

[Apache Jenkins Server]

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

Status: Failure

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

Changes:
No changes
 

Test results:
No tests ran.

Re: Oak Bundle versioning.

[Robert Munteanu]

On Fri, 2017-10-06 at 15:06 +0100, Ian Boston wrote:
> Hi,
> 
> On 6 October 2017 at 15:02, Robert Munteanu 
> wrote:
> 
> > Hi Ian,
> > 
> > Thanks for starting the discussion. I think this can be one of the
> > big
> > benefits of modularising Oak and I am interested in seeing this
> > being
> > done.
> > 
> > As you mentioned, it becomes easier to integrate various Oak
> > changes,
> > especially for consumers only depending on stable APIs.
> > 
> > On Thu, 2017-10-05 at 13:33 +0100, Ian Boston wrote:
> > > Obviously bundles remain the release unit, and the build must
> > > include
> > > OSGi
> > > based integration tests that validate a release is viable.
> > 
> > This brings about a question - what is an Oak release? If doing
> > per-
> > module releases, will we also do a "product" releases?
> > 
> > A product release in my view is - similar to the Sling Launchpad -
> > a
> > way of saying 'these module versions are guaranteed to work
> > together
> > beyond compilation and semantic versioning constraints'.
> > 
> > Also of interest is how/if we want to address the issue of
> > supporting
> > various module versions combinations. So if we have ( for instance
> > )
> > 
> > - oak-api 1.7.9
> > - oak-core 1.7.12
> > - oak-segment-tar 1.8.0
> > 
> > will these work together? Furthermore, which versions of oak-
> > upgrade
> > and oak-run are compatible with this combination?
> > 
> 
> 
> Perhaps, there needs to be a Oak Quickstart jar to define a
> combination of
> jars that work.
> Perhaps that is oak-run ?

Yes, that is one option.

The question is how do we actually expect consumers to define their
usage of Oak. 

One clear case is OSGi via Sling - and that can be defined via a Sling
feature.

Another is the one you mentioned - a runnable jar and that is oak-run.

Yeat another one can be embedding Oak in their project via
Maven/Gradle/etc dependencies . This is currently done in the oak-
examples module. Here we can consider defining an 'uber-pom' that is
used to pull in dependencies of a given Oak release.

Robert

Re: Oak Bundle versioning.

[Ian Boston]

Hi,

On 6 October 2017 at 15:02, Robert Munteanu  wrote:

> Hi Ian,
>
> Thanks for starting the discussion. I think this can be one of the big
> benefits of modularising Oak and I am interested in seeing this being
> done.
>
> As you mentioned, it becomes easier to integrate various Oak changes,
> especially for consumers only depending on stable APIs.
>
> On Thu, 2017-10-05 at 13:33 +0100, Ian Boston wrote:
> > Obviously bundles remain the release unit, and the build must include
> > OSGi
> > based integration tests that validate a release is viable.
>
> This brings about a question - what is an Oak release? If doing per-
> module releases, will we also do a "product" releases?
>
> A product release in my view is - similar to the Sling Launchpad - a
> way of saying 'these module versions are guaranteed to work together
> beyond compilation and semantic versioning constraints'.
>
> Also of interest is how/if we want to address the issue of supporting
> various module versions combinations. So if we have ( for instance )
>
> - oak-api 1.7.9
> - oak-core 1.7.12
> - oak-segment-tar 1.8.0
>
> will these work together? Furthermore, which versions of oak-upgrade
> and oak-run are compatible with this combination?
>


Perhaps, there needs to be a Oak Quickstart jar to define a combination of
jars that work.
Perhaps that is oak-run ?

Best Regards
Ian



>
> We should have these discussion first, and then (hopefully) switch to a
> more modular release process.
>
> Thanks,
>
> Robert
>

Re: Oak Bundle versioning.

[Robert Munteanu]

Hi Ian,

Thanks for starting the discussion. I think this can be one of the big
benefits of modularising Oak and I am interested in seeing this being
done.

As you mentioned, it becomes easier to integrate various Oak changes,
especially for consumers only depending on stable APIs.

On Thu, 2017-10-05 at 13:33 +0100, Ian Boston wrote:
> Obviously bundles remain the release unit, and the build must include
> OSGi
> based integration tests that validate a release is viable.

This brings about a question - what is an Oak release? If doing per-
module releases, will we also do a "product" releases? 

A product release in my view is - similar to the Sling Launchpad - a
way of saying 'these module versions are guaranteed to work together
beyond compilation and semantic versioning constraints'.

Also of interest is how/if we want to address the issue of supporting
various module versions combinations. So if we have ( for instance )

- oak-api 1.7.9
- oak-core 1.7.12
- oak-segment-tar 1.8.0

will these work together? Furthermore, which versions of oak-upgrade
and oak-run are compatible with this combination?

We should have these discussion first, and then (hopefully) switch to a
more modular release process.

Thanks,

Robert

Re: No documentation available for Oak MBeans?

[Jörg Hoh]

Hi Valentin,

that's an example of good documentation, but as you said, just a start. I
will try provide some more input and raise a jira issue.

Jörg

2017-10-03 16:27 GMT+02:00 Valentin Olteanu :

> Hi Jörg,
>
> I don't know all the Oak documentation, but I can start the list with a
> page I'm aware of:
> http://jackrabbit.apache.org/oak/docs/nodestore/segment/
> overview.html#monitoring-via-jmx
>
> HTH,
> Valentin
>
> On Thu, Sep 28, 2017 at 12:21 PM Jörg Hoh  wrote:
>
>> Hi,
>>
>> I see that with Oak 1.6 there are a lot of MBeans around which will likely
>> help me to monitor an OAK repository. But at the moment I can only try to
>> guess what the MBean properties describe. And therefor it's hard to
>> interprete the values and define thresholds for them.
>>
>> I've checked the Oak site but I did not find any documentation covering
>> the
>> MBeans, their properties and methods?
>>
>> Jörg
>>
>> --
>> Cheers,
>> Jörg Hoh,
>>
>> http://cqdump.wordpress.com
>> Twitter: @joerghoh
>>
>


-- 
Cheers,
Jörg Hoh,

http://cqdump.wordpress.com
Twitter: @joerghoh

Re: Waiting for an async index to be updated

[Alex Deparvu]

Hi Robert,

You could use the IndexStatsMBean [0] to poll for the indexing status,
waiting until indexing is completed.

hope this helps,
alex


[0]
https://github.com/stillalex/jackrabbit-oak/blob/trunk/oak-api/src/main/java/org/apache/jackrabbit/oak/api/jmx/IndexStatsMBean.java#L26



On Thu, Oct 5, 2017 at 4:49 PM, Robert Munteanu  wrote:

> Hi,
>
> In Sling we have some tests which validate that full text search is
> working. Occasionaly this test times out because the full-text lucene
> index is not updated and a traversal query is used. More details at
> [1].
>
> We should probably add a way of waiting for the index to be updated, so
> my question is - what would be the way to do that? Ideally we would do
> this from outside the Oak/Sling process, but can also deploy an OSGi
> bundle if needed.
>
> Thanks,
>
> Robert
>
>
> [1]: https://issues.apache.org/jira/browse/SLING-7169
>

BUILD FAILURE: Jackrabbit Oak - Build # 842 - Failure

[Apache Jenkins Server]

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

Status: Failure

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

Changes:
[stillalex] OAK-6753 Wrong binding in TokenConfigurationImpl
  - optimized case where there's a single entry (default)

 

Test results:
No tests ran.