Re: New Jackrabbit Committer: Mohit Kataria

[Tommaso Teofili]

Welcome to the team Mohit!

Regards,
Tommaso

On Thu, 8 Aug 2019 at 08:33, Marcel Reutegger  wrote:

> Hi,
>
> Please welcome Mohit Kataria as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Mohit committership based on his contributions. I'm happy to
> announce that he accepted the offer and that all the related
> administrative work has now been taken care of.
>
> Welcome to the team, Mohit!
>
> Regards
>  Marcel
>
>

Re: New Jackrabbit Committer: Nitin Gupta

[Tommaso Teofili]

Welcome to the team Nitin!

Regards,
Tommaso

On Thu, 8 Aug 2019 at 08:31, Marcel Reutegger  wrote:

> Hi,
>
> Please welcome Nitin Gupta as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Nitin committership based on his contributions. I'm happy to
> announce that he accepted the offer and that all the related
> administrative work has now been taken care of.
>
> Welcome to the team, Nitin!
>
> Regards
>  Marcel
>
>

Re: New Jackrabbit Committer: Mohit Kataria

[Tommaso Teofili]

Welcome to the team Mohit!

Regards,
Tommaso

On Thu, 8 Aug 2019 at 08:33, Marcel Reutegger  wrote:

> Hi,
>
> Please welcome Mohit Kataria as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Mohit committership based on his contributions. I'm happy to
> announce that he accepted the offer and that all the related
> administrative work has now been taken care of.
>
> Welcome to the team, Mohit!
>
> Regards
>  Marcel
>
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.25

[Tommaso Teofili]

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

Tommaso

On Tue, 16 Jul 2019 at 16:27, Davide Giannella  wrote:

> [X] +1 Release this package as Apache Jackrabbit Oak 1.4.25
> D.
>

Re: Intent to backport OAK-8235

[Tommaso Teofili]

thanks for the feedback Davide and Julian, in summary I share your same
concerns and therefore I don't have a good solution myself.
For now I've only backported it to the "safe" branches.
I'm thinking of backporting the previous upgrade to Solr 5.5.5 to branch
1.6, which would be JDK 1.7 compatible.

Regards,
Tommaso

Il giorno mar 11 giu 2019 alle ore 16:06 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 11.06.2019 12:42, Davide Giannella wrote:
> > ...
> > -1 on the additional branch. It will be yet one more branch to maintain
> > that will go very easily out of sync from the "official" 1.6.
> >
> > The only way to solve this is to increase the JDK compatibility. However
> > we have to account for consumer projects and their JDK compatibility.
> > They may have set JDK7 and cannot easily update JDK. Which in turns will
> > make any future 1.6 releases not suitable for the product.
> >
> > Other solution is to NOT backport the change as it is. We live with the
> > bugs in that area and produce some statement on the lines of: if you use
> > solr, you HAVE to upgrade to latest and greatest Oak release. Or at
> > lease 1.10.x.
> >
> > Or we manage to backport the security fixes in solr in a way that is JVM
> > compatible.
> >
> > Unfortunately I don't have a real solution.
>
> +1 on the summary...
>
>

Intent to backport OAK-8235

[Tommaso Teofili]

Hi all,

I'd like to backport OAK-8235
 to branch 1.10, 1.8 and
1.6.

For branch 1.10 and 1.8 everything should be just fine, however for 1.6 we
had set our java compatibility to JDK 1.7, however Solr 6.6.6 requires at
least JDK 1.8.
In most cases I simply wouldn't backport this, however Solr 6.6.x has some
security fixes that would be important to have for anyone using Solr.

I would create a branch of branch 1.6 for OAK-8235
 (e.g. 1.6-oak-8235) where
I would backport such changes and set the JDK compatibility version to 1.8.
The question then comes for releases, I don't think we would be willing to
release such "intermediate" branches.

What do you think?
Any other ideas on how to solve it ?

Regards,
Tommaso

Intent to backport OAK-8118 and OAK-8819 to the 1.8 branch

[Tommaso Teofili]

Hi all,

If no one objects, I'd like to backport OAK-8118 [1] and OAK-8819 [2]
to the 1.8 branch.

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/OAK-8118
[2] : https://issues.apache.org/jira/browse/OAK-8119

intento to backport OAK-8118 to branch 1.10

[Tommaso Teofili]

Hi all,

I'd like to backport OAK-8118 [1] to branch 1.10.

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/OAK-8118

intent to backport OAK-8072

[Tommaso Teofili]

Hi all,

I'd like to backport OAK-8072 [1] to 1.10 and 1.8 branches, if there's
no objection.

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/OAK-8072

Re: [VOTE] Release Apache Jackrabbit Oak 1.10.0

[Tommaso Teofili]

regarding the problem with OAK-7983, I think we can re spin the release now.
I've reverted the problematic commit and me and Vikas will follow up
with a patch which reintroduces the functionality from OAK-7947
without the mentioned bug as soon as possible.

Tommaso

Il giorno gio 10 gen 2019 alle ore 17:43 Tommaso Teofili
 ha scritto:
>
> see https://issues.apache.org/jira/browse/OAK-7983
>
> Il giorno gio 10 gen 2019 alle ore 17:38 Tommaso Teofili
>  ha scritto:
> >
> > while doing testing with trunk me and others have found out that the
> > changes for OAK-7947 can cause a NPE in case
> > LucenePropertyIndex#getIndexNode return null, therefore I think this
> > needs to be fixed before releasing 1.10.0, hence my -1.
> > I'll create an Oak issue right away.
> >
> > Regards,
> > Tommaso
> >
> > Il giorno gio 10 gen 2019 alle ore 16:55 Davide Giannella
> >  ha scritto:
> > >
> > >
> > >
> > > A candidate for the Jackrabbit Oak 1.10.0 release is available at:
> > >
> > > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.0/
> > >
> > > The release candidate is a zip archive of the sources in:
> > >
> > >
> > > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.0/
> > >
> > > The SHA1 checksum of the archive is
> > > 7cd2bc461395cdd4cdbdb626c4eecd315be2546a.
> > >
> > > A staged Maven repository is available for review at:
> > >
> > > https://repository.apache.org/
> > >
> > > The command for running automated checks against this release candidate 
> > > is:
> > >
> > > # run in SVN checkout of
> > > https://dist.apache.org/repos/dist/dev/jackrabbit
> > > $ sh check-release.sh oak 1.10.0
> > > 7cd2bc461395cdd4cdbdb626c4eecd315be2546a
> > >
> > > Please vote on releasing this package as Apache Jackrabbit Oak 1.10.0.
> > > 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.10.0
> > > [ ] -1 Do not release this package because...
> > >
> > > D.

Re: [VOTE] Release Apache Jackrabbit Oak 1.10.0

[Tommaso Teofili]

see https://issues.apache.org/jira/browse/OAK-7983

Il giorno gio 10 gen 2019 alle ore 17:38 Tommaso Teofili
 ha scritto:
>
> while doing testing with trunk me and others have found out that the
> changes for OAK-7947 can cause a NPE in case
> LucenePropertyIndex#getIndexNode return null, therefore I think this
> needs to be fixed before releasing 1.10.0, hence my -1.
> I'll create an Oak issue right away.
>
> Regards,
> Tommaso
>
> Il giorno gio 10 gen 2019 alle ore 16:55 Davide Giannella
>  ha scritto:
> >
> >
> >
> > A candidate for the Jackrabbit Oak 1.10.0 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.0/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.0/
> >
> > The SHA1 checksum of the archive is
> > 7cd2bc461395cdd4cdbdb626c4eecd315be2546a.
> >
> > A staged Maven repository is available for review at:
> >
> > https://repository.apache.org/
> >
> > The command for running automated checks against this release candidate is:
> >
> > # run in SVN checkout of
> > https://dist.apache.org/repos/dist/dev/jackrabbit
> > $ sh check-release.sh oak 1.10.0
> > 7cd2bc461395cdd4cdbdb626c4eecd315be2546a
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.10.0.
> > 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.10.0
> > [ ] -1 Do not release this package because...
> >
> > D.

Re: [VOTE] Release Apache Jackrabbit Oak 1.10.0

[Tommaso Teofili]

while doing testing with trunk me and others have found out that the
changes for OAK-7947 can cause a NPE in case
LucenePropertyIndex#getIndexNode return null, therefore I think this
needs to be fixed before releasing 1.10.0, hence my -1.
I'll create an Oak issue right away.

Regards,
Tommaso

Il giorno gio 10 gen 2019 alle ore 16:55 Davide Giannella
 ha scritto:
>
>
>
> A candidate for the Jackrabbit Oak 1.10.0 release is available at:
>
> https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.10.0/
>
> The release candidate is a zip archive of the sources in:
>
>
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.10.0/
>
> The SHA1 checksum of the archive is
> 7cd2bc461395cdd4cdbdb626c4eecd315be2546a.
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/
>
> The command for running automated checks against this release candidate is:
>
> # run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit
> $ sh check-release.sh oak 1.10.0
> 7cd2bc461395cdd4cdbdb626c4eecd315be2546a
>
> Please vote on releasing this package as Apache Jackrabbit Oak 1.10.0.
> 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.10.0
> [ ] -1 Do not release this package because...
>
> D.

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

[Tommaso Teofili]

thanks Francesco and Robert for your replies.
I think what the query engine is missing to behave like the segment
node store is that one OSGi service which gets picked up with all
those required wirings, so that we can pass it down the stack.
However it sounds like the latter option is more work but in the end
(hopefully) better in terms of code quality / testability / etc.

Regards,
Tommaso
Il giorno mer 28 nov 2018 alle ore 11:43 Robert Munteanu
 ha scritto:
>
> On Wed, 2018-11-28 at 11:34 +0100, Francesco Mari wrote:
> > On Tue, 27 Nov 2018 at 11:45, Tommaso Teofili <
> > tommaso.teof...@gmail.com>
> > wrote:
> >
> > > After having dig into the code for a while I can see following
> > options:
> > > - have a dedicated OSGi service on the query side that can be then
> > > polled in a static way from QueryEngineImpl in order to obtain such
> > a
> > > reference (see patch from OAK-7904 [1])
> > >
> >
> > I suggest you don't pursue this option. I find that every service
> > introduces additional complexity and hinders the testability of the
> > code.
> > In oak-segment-tar we pushed all the OSGi bits to a couple of
> > services
> > (read below) and everything else is just plain Java code that
> > explicitly
> > declares its dependencies. The API is clearer and the code is much
> > more
> > testable. You don't want to resort on oak-it-osgi to test your stuff
> > ;)
>
> Note that with OSGi R7 you can use constructor injection, and that
> makes it really easy to construct your object graphs manually for
> testing. So no need to resort to ITs for testing OSGi-aware components.
>
> Not really arguing for one option or the other, but wanted to make sure
> everyone is aware of the most recent changes.
>
> Thanks,
>
> Robert
>

Re: [Monitoring] - Provisioning StatisticsProvider in Oak

[Tommaso Teofili]

p.s.:

[1] : 
https://issues.apache.org/jira/browse/OAK-7904?focusedCommentId=16697298=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16697298
Il giorno mar 27 nov 2018 alle ore 11:38 Tommaso Teofili
 ha scritto:
>
> Hi all,
>
> since a few days I'm trying to capture some simple stats on the Oak
> query engine and I'm struggling with instrumenting the
> StatisticsProvider which is used to update MeterStats and the likes.
>
> While everything has gone smoothly on the indexing side as obtaining a
> StatisticsProvider was as simple as attaching a @Reference to obtain
> the StatisticsProvider OSGi service in LuceneIndexProviderService,
> this seems hardly possible on the query side.
> In fact QueryEngineImpl and its "companions" classes in
> org.apache.jackrabbit.oak.query package (from oak-core) do not use
> OSGi at all and this seems to make it very hard to obtain a
> StatisticsProvider instance.
>
> After having dig into the code for a while I can see following options:
> - have a dedicated OSGi service on the query side that can be then
> polled in a static way from QueryEngineImpl in order to obtain such a
> reference (see patch from OAK-7904 [1])
> - pass the StatisticsProvider instances down the whole stack from Oak
> class (or from MutableRoot/ImmubtableRoot)
>
> I personally don't like any of the above so I was seeking for some
> alternative solution which wouldn't screw up design / encapsulation
> and all programming best practice that much.
> Is there a way to obtain the StatisticProvider reference from a non
> OSGi context which wouldn't involve pushing a Whiteboard object down
> from Oak to QueryEngineImpl ?
>
> Regards,
> Tommaso

[Monitoring] - Provisioning StatisticsProvider in Oak

[Tommaso Teofili]

Hi all,

since a few days I'm trying to capture some simple stats on the Oak
query engine and I'm struggling with instrumenting the
StatisticsProvider which is used to update MeterStats and the likes.

While everything has gone smoothly on the indexing side as obtaining a
StatisticsProvider was as simple as attaching a @Reference to obtain
the StatisticsProvider OSGi service in LuceneIndexProviderService,
this seems hardly possible on the query side.
In fact QueryEngineImpl and its "companions" classes in
org.apache.jackrabbit.oak.query package (from oak-core) do not use
OSGi at all and this seems to make it very hard to obtain a
StatisticsProvider instance.

After having dig into the code for a while I can see following options:
- have a dedicated OSGi service on the query side that can be then
polled in a static way from QueryEngineImpl in order to obtain such a
reference (see patch from OAK-7904 [1])
- pass the StatisticsProvider instances down the whole stack from Oak
class (or from MutableRoot/ImmubtableRoot)

I personally don't like any of the above so I was seeking for some
alternative solution which wouldn't screw up design / encapsulation
and all programming best practice that much.
Is there a way to obtain the StatisticProvider reference from a non
OSGi context which wouldn't involve pushing a Whiteboard object down
from Oak to QueryEngineImpl ?

Regards,
Tommaso

Re: Backporting similarity search to Oak 1.8

[Tommaso Teofili]

+1, the patch looks good to me.

Tommaso
Il giorno mer 19 set 2018 alle ore 22:33 Matt Ryan  ha scritto:
>
> Hi oak-dev,
>
> I’ve just created OAK-7769 in which I would like us to consider backporting
> the similarity search feature that Tommaso implemented in OAK-7575 to Oak
> 1.8.  There is a patch file included in the issue which applies cleanly to
> 1.8 and all unit tests pass.  It includes unit tests written for OAK-7575.
> The change is almost all additive, meaning there is little existing
> functionality in 1.8 that is being modified.
>
> Tommaso has viewed the patch; IIUC he feels comfortable with it but I will
> allow him to speak for himself and comment further one way or the other.
>
>
> -MR

Re: [jira] [Commented] (OAK-7764) Build Jackrabbit Oak #1654 failed

[Tommaso Teofili]

this should be fixed in r1841328.
Il giorno mer 19 set 2018 alle ore 14:49 Hudson (JIRA)
 ha scritto:
>
>
> [ 
> https://issues.apache.org/jira/browse/OAK-7764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620533#comment-16620533
>  ]
>
> Hudson commented on OAK-7764:
> -
>
> Build is still failing.
> Failed run: [Jackrabbit Oak 
> #1658|https://builds.apache.org/job/Jackrabbit%20Oak/1658/] [console 
> log|https://builds.apache.org/job/Jackrabbit%20Oak/1658/console]
>
> > Build Jackrabbit Oak #1654 failed
> > -
> >
> > Key: OAK-7764
> > URL: https://issues.apache.org/jira/browse/OAK-7764
> > Project: Jackrabbit Oak
> >  Issue Type: Bug
> >  Components: continuous integration
> >Reporter: Hudson
> >Priority: Major
> >
> > No description is provided
> > The build Jackrabbit Oak #1654 has failed.
> > First failed run: [Jackrabbit Oak 
> > #1654|https://builds.apache.org/job/Jackrabbit%20Oak/1654/] [console 
> > log|https://builds.apache.org/job/Jackrabbit%20Oak/1654/console]
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.22

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 26 giu 2018 alle ore 10:50 Alex Deparvu 
ha scritto:

> [X] +1 Release this package as Apache Jackrabbit Oak 1.4.22
>
> [INFO] Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T09:58:13+02:00)
> [INFO] OS name: "mac os x", version: "10.13.5", arch: "x86_64", family:
> "mac"
> [INFO] Java version: 1.8.0_121, vendor: Oracle Corporation
>
> alex
>
>
>
> On Mon, Jun 25, 2018 at 6:33 PM Manfred Baedke 
> wrote:
>
> > A candidate for the Jackrabbit Oak 1.4.22 release is available at:
> >
> >  https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.4.22/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.4.22/
> >
> > The SHA1 checksum of the archive is
> > ab43b3c40d5dc21c7110ef5c9021e37b1a779b20.
> >
> > A staged Maven repository is available for review at:
> >
> >  https://repository.apache.org/
> >
> > The command for running automated checks against this release candidate
> is:
> >
> >  # run in SVN checkout of
> > https://dist.apache.org/repos/dist/dev/jackrabbit
> >  $ sh check-release.sh oak 1.4.22
> > ab43b3c40d5dc21c7110ef5c9021e37b1a779b20
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.4.22.
> > 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.22
> >  [ ] -1 Do not release this package because...
> >
> >
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.12

[Tommaso Teofili]

+1 all checks ok, svn tag build ok.

Regards,
Tommaso

Il giorno mar 29 mag 2018 alle ore 10:12 Marcel Reutegger
 ha scritto:

> On 28.05.18 16:42, Manfred Baedke wrote:
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.6.12.
> > The vote is open for the next 72 hours and passes if a majority of at
> > least three +1 Jackrabbit PMC votes are cast.
>
> All checks OK.
>
> +1 Release this package as Apache Jackrabbit Oak 1.6.12
>
> Regards
>   Marcel
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.11

[Tommaso Teofili]

+1, all checks ok

Tommaso

Il giorno mer 4 apr 2018 alle ore 10:10 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 2018-04-04 08:16, Amit Jain wrote:
> > ...
>
> [X] +1 Release this package as Apache Jackrabbit Oak 1.6.11
>
> ...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
>

oak-search module

[Tommaso Teofili]

Hi all,

In the context of creating an (abstract) implementation for Oak full text
indexes [1], I'd like to create a new module called _oak-search_.
Such module will contain:
- implementation agnostic utilities for full text search (e.g. aggregation
utilities)
- implementation agnostic SPIs to be extended by implementors (currently we
expose SPIs in oak-lucene whose signatures include Lucene specific APIs)
- abstract full text editor / query index implementations
- text extraction utilities

Please share your feedback / opinions / concerns.

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/OAK-3336

Re: adaptTo() 2018: Tickets now available / Start Call for Papers

[Tommaso Teofili]

I am sorry if your company lost money with adaptTo, that's organizer's
decision whether to make it or not and how much to ask people to pay, no
doubt about it. Of course good venue / food / etc are expensive, but still
IMHO it sounds a crazy price (and it's an early bird!) for an event meant
to gather people with possibly different backgrounds from our communities.

My 2 cents,
Tommaso

Il giorno gio 1 feb 2018 alle ore 18:01 Stefan Seifert <
sseif...@pro-vision.de> ha scritto:

> hello tommaso.
>
> thanks for the feedback...
>
> we did not make the decision on the prices lightheartedly. in the last 7
> years we never made any profit with adaptTo() (and did not intend to do
> so), but most times paid on top, even with having some sponsors. this year
> we have a bigger location, having a good environment, food, (working) WLAN
> etc. - that's all expensive.
>
> please note there is 50% discount on the regular price for apache
> committers (any project), perhaps this hint is a bit hidden in our website.
>
> stefan
>
>
> >-Original Message-
> >From: Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
> >Sent: Thursday, February 1, 2018 5:52 PM
> >To: dev@jackrabbit.apache.org
> >Cc: us...@jackrabbit.apache.org; oak-...@jackrabbit.apache.org
> >Subject: Re: adaptTo() 2018: Tickets now available / Start Call for Papers
> >
> >Hi Sebastian,
> >
> >here's my feedback: 599€ as an early bird price sounds crazy and it's all
> >but inclusive for people not being backed by companies willing to pay the
> >conference.
> >
> >Regards,
> >Tommaso
> >
> >Il giorno gio 1 feb 2018 alle ore 15:57 Stefan Seifert <
> >sseif...@pro-vision.de> ha scritto:
> >
> >> Dear adaptTo() Community,
> >>
> >> the sale of tickets for adaptTo() 2018 is open.
> >>
> >> Get your Early-Bird-Ticket here: https://adapt.to/tickets
> >>
> >> We also started the Call for Papers today! If you would like to be a
> >> speaker, please check out https://adapt.to/cfp
> >>
> >> Focusing on Apache Sling, Apache Felix and Apache Jackrabbit, the
> >> adaptTo() conference in Potsdam (near Berlin) is aimed at developers
> >using
> >> some or all if this stack.
> >>
> >> This year´s conference date is 10 - 12 September; latest information can
> >> be found on https://adapt.to
> >>
> >> Kind regards on behalf of the adaptTo() Team,
> >> Stefan
> >>
> >>
> >>
>

Re: adaptTo() 2018: Tickets now available / Start Call for Papers

[Tommaso Teofili]

sorry, I meant to write Stefan, not Sebastian, of course.

Regards,
Tommaso

Il giorno gio 1 feb 2018 alle ore 17:52 Tommaso Teofili <
tommaso.teof...@gmail.com> ha scritto:

> Hi Sebastian,
>
> here's my feedback: 599€ as an early bird price sounds crazy and it's all
> but inclusive for people not being backed by companies willing to pay the
> conference.
>
> Regards,
> Tommaso
>
>
> Il giorno gio 1 feb 2018 alle ore 15:57 Stefan Seifert <
> sseif...@pro-vision.de> ha scritto:
>
>> Dear adaptTo() Community,
>>
>> the sale of tickets for adaptTo() 2018 is open.
>>
>> Get your Early-Bird-Ticket here: https://adapt.to/tickets
>>
>> We also started the Call for Papers today! If you would like to be a
>> speaker, please check out https://adapt.to/cfp
>>
>> Focusing on Apache Sling, Apache Felix and Apache Jackrabbit, the
>> adaptTo() conference in Potsdam (near Berlin) is aimed at developers using
>> some or all if this stack.
>>
>> This year´s conference date is 10 - 12 September; latest information can
>> be found on https://adapt.to
>>
>> Kind regards on behalf of the adaptTo() Team,
>> Stefan
>>
>>
>>

Re: adaptTo() 2018: Tickets now available / Start Call for Papers

[Tommaso Teofili]

Hi Sebastian,

here's my feedback: 599€ as an early bird price sounds crazy and it's all
but inclusive for people not being backed by companies willing to pay the
conference.

Regards,
Tommaso

Il giorno gio 1 feb 2018 alle ore 15:57 Stefan Seifert <
sseif...@pro-vision.de> ha scritto:

> Dear adaptTo() Community,
>
> the sale of tickets for adaptTo() 2018 is open.
>
> Get your Early-Bird-Ticket here: https://adapt.to/tickets
>
> We also started the Call for Papers today! If you would like to be a
> speaker, please check out https://adapt.to/cfp
>
> Focusing on Apache Sling, Apache Felix and Apache Jackrabbit, the
> adaptTo() conference in Potsdam (near Berlin) is aimed at developers using
> some or all if this stack.
>
> This year´s conference date is 10 - 12 September; latest information can
> be found on https://adapt.to
>
> Kind regards on behalf of the adaptTo() Team,
> Stefan
>
>
>

Re: adaptTo() 2018: Tickets now available / Start Call for Papers

[Tommaso Teofili]

Hi Sebastian,

here's my feedback: 599€ as an early bird price sounds crazy and it's all
but inclusive for people not being backed by companies willing to pay the
conference.

Regards,
Tommaso

Il giorno gio 1 feb 2018 alle ore 15:57 Stefan Seifert <
sseif...@pro-vision.de> ha scritto:

> Dear adaptTo() Community,
>
> the sale of tickets for adaptTo() 2018 is open.
>
> Get your Early-Bird-Ticket here: https://adapt.to/tickets
>
> We also started the Call for Papers today! If you would like to be a
> speaker, please check out https://adapt.to/cfp
>
> Focusing on Apache Sling, Apache Felix and Apache Jackrabbit, the
> adaptTo() conference in Potsdam (near Berlin) is aimed at developers using
> some or all if this stack.
>
> This year´s conference date is 10 - 12 September; latest information can
> be found on https://adapt.to
>
> Kind regards on behalf of the adaptTo() Team,
> Stefan
>
>
>

intent to backport OAK-4318 to branch 1.6

[Tommaso Teofili]

Hi all,

I'd like to backport upgrade to Solr 5.5.5 (OAK-4318) to branch 1.6.

Regards,
Tommaso

Re: [VOTE] Release Apache Jackrabbit Oak 1.8.0

[Tommaso Teofili]

+1

build and sigs ok

Tommaso

Il giorno mar 9 gen 2018 alle ore 14:05 Robert Munteanu 
ha scritto:

> On Tue, 2018-01-09 at 11:53 +, Davide Giannella wrote:
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.8.0.
>
> +1
>
> > [INFO]
> 
> > [INFO] Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T10:58:13+03:00)
> > [INFO] OS name: "linux", version: "4.13.11-0-default", arch: "amd64",
> family: "unix"
> > [INFO] Java version: 1.8.0_151, vendor: Oracle Corporation
> > [INFO]
> 
>
> Thanks,
>
> Robert

intento to backport OAK-4055 to branch 1.2

[Tommaso Teofili]

Hi all,

I'd like to backport OAK-4055 [1] to branch 1.2 to make it possible to use
a Solr index for a subtree instead of for the whole repository.

Regards,
Tommaso

[1] : http://issues.apache.org/jira/browse/OAK-4055

Re: Build failure due to out of heap in oak-solr

[Tommaso Teofili]

thanks Michael, now I should be able to reproduce it by manually setting
the max heap to 512M.

Regards,
Tommaso

Il giorno ven 15 dic 2017 alle ore 12:52 Michael Dürig 
ha scritto:

>
>
> On 15.12.17 12:41, Robert Munteanu wrote:
> > On Fri, 2017-12-15 at 15:18 +0530, Chetan Mehrotra wrote:
> >>> Caused by: java.lang.OutOfMemoryError: Java heap space
> >>
> >> The build is failing due to OOM in oak-solr-core
> >> https://builds.apache.org/job/Jackrabbit%20Oak/1090/
> >
> > FWIW, the windows build does not fail ( yay?)
> >
> >https://builds.apache.org/job/Jackrabbit-Oak-Windows/
> >
> > Granted, I have not set any -Xmx flag for this job so I don't know how
> > much memory it's taking. I see the 'main' job uses -Xmx2g, so maybe we
> > can bump it up to -Xmx3g, just as a test?
> >
>
> We shouldn't add any memory setting in the Jenins jobs but rely on the
> test.opts.memory property of the parent pom.xml. This is intentionally
> set to 512M so we find out about potential regressions early.
>
> Michael
>

Re: svn commit: r1818056 - /jackrabbit/oak/trunk/oak-solr-core/src/test/resources/solr/oak/conf/solrconfig.xml

[Tommaso Teofili]

thanks, you've been faster than me :)

Il giorno mer 13 dic 2017 alle ore 20:22  ha scritto:

> Author: rombert
> Date: Wed Dec 13 19:22:28 2017
> New Revision: 1818056
>
> URL: http://svn.apache.org/viewvc?rev=1818056=rev
> Log:
> OAK-4138 - Upgrade oak-solr to Solr 5.x
>
> Fix syntax error in solrconfig.xml
>
> Modified:
>
> jackrabbit/oak/trunk/oak-solr-core/src/test/resources/solr/oak/conf/solrconfig.xml
>
> Modified:
> jackrabbit/oak/trunk/oak-solr-core/src/test/resources/solr/oak/conf/solrconfig.xml
> URL:
> http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-solr-core/src/test/resources/solr/oak/conf/solrconfig.xml?rev=1818056=1818055=1818056=diff
>
> ==
> ---
> jackrabbit/oak/trunk/oak-solr-core/src/test/resources/solr/oak/conf/solrconfig.xml
> (original)
> +++
> jackrabbit/oak/trunk/oak-solr-core/src/test/resources/solr/oak/conf/solrconfig.xml
> Wed Dec 13 19:22:28 2017
> @@ -555,7 +555,7 @@ Lucene will flush based on whichever lim
> prepared but there is no current registered searcher to handle
> requests or to gain autowarming data from.
>
> -
> +-->
>
>  

Re: Experimental build for Oak on Windows

[Tommaso Teofili]

+1 thanks Robert, I had the same experience Michael had a while back.
Also to me it looked like many test failures were false negatives, but it
may well be that some tests fail reliably on Windows and I didn't notice
that.

Regards,
Tommaso


Il giorno gio 7 dic 2017 alle ore 09:11 Michael Dürig 
ha scritto:

>
> Thanks Robert for taking this up again. Almost exactly a year ago I
> spent some time in understanding Jenkins issues [1]. This showed that
> back then infrastructure problems prevailed by large. Only a few issues
> reported by Jenkins were actual regressions. I would be interested to
> see whether and how the situation changed in the meanwhile.
>
> Michael
>
> [1]
>
> https://lists.apache.org/thread.html/8f5734bc8a70c6a85f566a7fc98efed088cb55e05ce9dde864625473@%3Coak-dev.jackrabbit.apache.org%3E
>
> On 06.12.17 12:48, Robert Munteanu wrote:
> > Hi,
> >
> > I set up yesterday an experimental build for Oak on Windows
> >
> >https://builds.apache.org/job/Jackrabbit-Oak-Windows/
> >
> > It _seems_ to be working fine, but I've marked it as experimental given
> > the historical stability issues with ASF Windows bots. Feel free to
> > double-check with it in case you have doubts regarding the status of
> > the build on Windows.
> >
> > I'll keep it alive for a couple of weeks to assess its stability, and
> > then we can discuss whether we want to promote it to a 'proper' job
> > that we actually pay attention to and that sends notifications.
> >
> > Thanks,
> >
> > Robert
> >
>

Re: svn commit: r1816834 - in /jackrabbit/oak/trunk/oak-benchmarks: pom.xml src/main/java/org/apache/jackrabbit/oak/benchmark/FullTextSolrSearchTest.java

[Tommaso Teofili]

thanks Amit!

Il giorno ven 1 dic 2017 alle ore 12:15  ha scritto:

> Author: amitj
> Date: Fri Dec  1 11:15:23 2017
> New Revision: 1816834
>
> URL: http://svn.apache.org/viewvc?rev=1816834=rev
> Log:
> OAK-4318: Upgrade oak-solr to Solr 5.x
>
> - Tentatively fixed with updating solr-core dependency to solr.version and
> converting SolrServer to SolrClient
>
> Modified:
> jackrabbit/oak/trunk/oak-benchmarks/pom.xml
>
> jackrabbit/oak/trunk/oak-benchmarks/src/main/java/org/apache/jackrabbit/oak/benchmark/FullTextSolrSearchTest.java
>
> Modified: jackrabbit/oak/trunk/oak-benchmarks/pom.xml
> URL:
> http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-benchmarks/pom.xml?rev=1816834=1816833=1816834=diff
>
> ==
> --- jackrabbit/oak/trunk/oak-benchmarks/pom.xml (original)
> +++ jackrabbit/oak/trunk/oak-benchmarks/pom.xml Fri Dec  1 11:15:23 2017
> @@ -170,7 +170,7 @@
>  
>  org.apache.solr
>  solr-core
> -${lucene.version}
> +${solr.version}
>  
>  
>  org.apache.lucene
>
> Modified:
> jackrabbit/oak/trunk/oak-benchmarks/src/main/java/org/apache/jackrabbit/oak/benchmark/FullTextSolrSearchTest.java
> URL:
> http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-benchmarks/src/main/java/org/apache/jackrabbit/oak/benchmark/FullTextSolrSearchTest.java?rev=1816834=1816833=1816834=diff
>
> ==
> ---
> jackrabbit/oak/trunk/oak-benchmarks/src/main/java/org/apache/jackrabbit/oak/benchmark/FullTextSolrSearchTest.java
> (original)
> +++
> jackrabbit/oak/trunk/oak-benchmarks/src/main/java/org/apache/jackrabbit/oak/benchmark/FullTextSolrSearchTest.java
> Fri Dec  1 11:15:23 2017
> @@ -43,7 +43,7 @@ import org.apache.jackrabbit.oak.plugins
>  import
> org.apache.jackrabbit.oak.plugins.index.solr.server.EmbeddedSolrServerProvider;
>  import
> org.apache.jackrabbit.oak.plugins.index.solr.server.SolrServerProvider;
>  import
> org.apache.jackrabbit.oak.plugins.index.solr.util.SolrIndexInitializer;
> -import org.apache.solr.client.solrj.SolrServer;
> +import org.apache.solr.client.solrj.SolrClient;
>  import org.apache.solr.client.solrj.embedded.EmbeddedSolrServer;
>  import org.slf4j.Logger;
>  import org.slf4j.LoggerFactory;
> @@ -114,7 +114,7 @@ public class FullTextSolrSearchTest exte
>  embeddedSolrServerConfiguration =
> embeddedSolrServerConfiguration.withHttpConfiguration("/solr", 8983);
>  }
>  EmbeddedSolrServerProvider embeddedSolrServerProvider =
> embeddedSolrServerConfiguration.getProvider();
> -SolrServer solrServer =
> embeddedSolrServerProvider.getSolrServer();
> +SolrClient solrServer =
> embeddedSolrServerProvider.getSolrServer();
>  if (storageEnabled != null && !storageEnabled) {
>  // change schema.xml and reload the core
>  File schemaXML = new File(solrHome.getAbsolutePath() +
> "/oak/conf", "schema.xml");
> @@ -131,7 +131,7 @@ public class FullTextSolrSearchTest exte
>
>  @Override
>  protected void afterSuite() throws Exception {
> -SolrServer solrServer = serverProvider.getSolrServer();
> +SolrClient solrServer = serverProvider.getSolrServer();
>  if (solrServer != null) {
>  solrServer.shutdown();
>  }
>
>
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.7

[Tommaso Teofili]

+1, all checks ok

Tommaso

Il giorno mar 28 nov 2017 alle ore 11:12 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 2017-11-28 10:15, Davide Giannella wrote:
> > ...
>
> [X] +1 Release this package as Apache Jackrabbit Oak 1.6.7
>
> 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_151, vendor: Oracle Corporation
>
> Best regards, Julian
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.6.6

[Tommaso Teofili]

+1

all checks ok

Tommaso

Il giorno mar 31 ott 2017 alle ore 10:28 Amit Jain  ha
scritto:

> +1 Release this package as Apache Jackrabbit Oak 1.6.6
>
> Thanks
> Amit
>
> On Mon, Oct 30, 2017 at 2:57 PM, Davide Giannella 
> wrote:
> >
> >
> > A candidate for the Jackrabbit Oak 1.6.6 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.6.6/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> >
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.6.6/
> >
> > The SHA1 checksum of the archive is
> > d11179243a206cbb727a18d47025fca18803b4d6.
> >
> > 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.6.6
> d11179243a206cbb727a18d47025fca18803b4d6
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.6.6.
> > 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.6.6
> > [ ] -1 Do not release this package because...
> >
> > D.
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.10

[Tommaso Teofili]

+1 all checks ok.

Regards,
Tommaso

Il giorno mar 24 ott 2017 alle ore 17:41 Vikas Saurabh <
vikas.saur...@gmail.com> ha scritto:

> On Mon, Oct 23, 2017 at 10:02 PM, Davide Giannella 
> wrote:
> >
> > [X] +1 Release this package as Apache Jackrabbit Oak 1.7.10
>
> Thanks,
> Vikas
>

Re: [VOTE] Release Apache Jackrabbit 2.15.7

[Tommaso Teofili]

+1, all checks ok

Tommaso

Il giorno mar 24 ott 2017 alle ore 17:09 Vikas Saurabh <
vikas.saur...@gmail.com> ha scritto:

> On Sun, Oct 22, 2017 at 1:58 PM, Julian Reschke 
> wrote:
> >
> > [X] +1 Release this package as Apache Jackrabbit 2.15.7
>
> Thanks,
> Vikas
>

Re: Consider making Oak 1.8 an Oak 2.0

[Tommaso Teofili]

+1 it makes sense.

Tommaso

Il giorno ven 13 ott 2017 alle ore 17:01 Matt Ryan  ha
scritto:

> Hi,
>
> Makes good sense to me.  Cutting the next release as a major version
> reflects the high amount of change in dependencies that the downstream
> should expect.
>
> -MR
>
>
> On October 13, 2017 at 8:58:38 AM, Angela Schreiber (
> anch...@adobe.com.invalid) wrote:
>
> hi
>
> given the fact that the m12n topic is quite an effort and has major
> consequences for oak, i would like to propose that we discuss the option
> of making the next stable release from trunk a 2.0 instead of just a next
> 1.8.
>
> imho it would better reflect the changes if we compare it to a minor step
> from 1.4 to 1.6.
>
> wdyt?
>
> kind regards
> angela
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.8

[Tommaso Teofili]

+1

Il giorno lun 25 set 2017 alle ore 22:53 Robert Munteanu 
ha scritto:

> On Mon, 2017-09-25 at 21:15 +0100, Davide Giannella wrote:
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.7.8.
>
> +1
>
> Robert

Re: OAK-6575 - A word of caution

[Tommaso Teofili]

thanks Ian for taking care of including all the provided feedback, I
finally managed to review the patches and it looks very good now as it
sounds simpler and more inline with the overall Oak design.

Thanks again,
Tommaso



Il giorno gio 7 set 2017 alle ore 16:39 Ian Boston  ha
scritto:

> On 7 September 2017 at 14:41, Francesco Mari 
> wrote:
>
> > On Thu, Sep 7, 2017 at 11:05 AM, Ian Boston  wrote:
> > > On 7 September 2017 at 07:22, Ian Boston  wrote:
> > >
> > >> Hi,
> > >>
> > >> On 6 September 2017 at 22:43, Michael Dürig 
> wrote:
> > >>
> > >>>
> > >>>
> > >>> On 06.09.17 23:08, Michael Dürig wrote:
> > >>>
> > 
> >  Hi,
> > 
> >  On 05.09.17 14:09, Ian Boston wrote:
> > 
> > > Repeating the comment to on OAK-6575 here for further discussion. 2
> > new
> > > Patches exploring both options.
> > >
> > 
> >  I would actually prefer the original patch (
> >  https://github.com/ieb/jackrabbit-oak/compare/trunk...ieb:O
> >  AK-6575?expand=1) in most parts. However I have concerns regarding
> the
> >  generality of the new OakConversionService API as mentioned in my
> > previous
> >  mail. I would be more comfortable if this could be restricted to
> > something
> >  that resembles more like a "URIProvider", which given a blob returns
> > an URI.
> > 
> >  On the implementation side, why do we need to introduce the
> adaptable
> >  machinery? Couldn't we re-use the Whiteboard and OSGiWhiteBoard
> > mechanisms
> >  instead? I think these could be used to track URIProvider instances
> >  registered by the various blob stores.
> > 
> > 
> > >>> See https://github.com/mduerig/jackrabbit-oak/commit/2709c097b01
> > >>> a006784b7011135efcbbe3ce1ba88 for a *really* quickly hacked together
> > and
> > >>> entirely untested POC. But it should get the idea across though.
> > >>
> > >>
> > >>
> > >> Thank you.
> > >> That makes sense.
> > >> I think it only needs the  java/org/apache/jackrabbit/
> > >> oak/blob/cloud/aws/s3/CloudFrontS3SignedUrlAdapterFactory.java and the
> > >> API to be inside Oak, everything else can be in Sling.
> > >> I'll update my patch and do a 2 options for Sling.
> > >>
> > >
> > >
> > >
> > >
> > > https://github.com/ieb/jackrabbit-oak/compare/trunk..
> > .ieb:OAK-6575-3?expand=1
> > >
> > > and
> > >
> > >
> https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3?expand=1
> > >
> > > wdyt ?
> >
> > I like this a lot. It keeps Oak's side simple and cleanly integrates
> > Oak's lower-level services in Sling.
> >
>
>
> Good news.
> I think we should hold off committing the patch until Monday or Tuesday to
> give those who may be offline this week a chance to comment. In particular
> I have not seen a comment from Angela who I would expect to have a view as
> this is acl/security related. That is assuming she is back online next
> week.
>
> Best Regards
> Ian
>
>
> >
> > > Obviously the second patch needs to be discussed with Sling dev, but is
> > > should not be too contentious.
> > >
> > > Best Regards
> > > Ian
> > >
> > >
> > >
> > >>
> > >> I think that should address others concerns since it drops all signs
> of
> > >> any generic object to object conversion from Oak (Francesco), and
> > doesn't
> > >> require wide scale fragile changes with implied requirements being
> > placed
> > >> on how intermediate classes are connected and behave (mine).
> > >>
> > >> Best Regards
> > >> Ian
> > >>
> > >>
> > >>>
> > >>> Michael
> > >>>
> > >>
> > >>
> >
>

Re: OAK-6575 - A word of caution

[Tommaso Teofili]

I share Francesco's concerns, the same way I shared them when we first
discussed this way back; I tried to express my doubts on the current
proposal in the email thread for OAK-6575 (linked also in Francesco's
email), which got ignored; that's fine as long as the majority of us is
happy with the current solution, probably it's just me having this not so
good feeling here with me, that some of us want this feature to be in a way
or another.

Tommaso



Il giorno lun 4 set 2017 alle ore 14:45 Francesco Mari <
mari.france...@gmail.com> ha scritto:

> On Mon, Sep 4, 2017 at 2:13 PM, Chetan Mehrotra
>  wrote:
> > Adaptable pattern in itself was not much discussed at that time.
>
> Concerns about the adaptable pattern and its implications in data
> encapsulation were expressed in the old thread at [1], [2], [3], [4],
> and in other messages in the same thread. In the new thread, it was
> pointed out [5] that solving the problem discussed in OAK-6575 is
> orthogonal to the introduction of the adaptable pattern. Moreover, in
> the new thread some concerns were expressed about the adaptable
> pattern as well at [6] and [7].
>
> [1]:
> https://lists.apache.org/thread.html/8b0021987b824b096ea9b470a4edd5edf1a246ef10548a2343ad4668@1462438837@%3Coak-dev.jackrabbit.apache.org%3E
> [2]:
> https://lists.apache.org/thread.html/4c352d247da81ca6ab05abfb7c53368fb88ed3c587fb09b42b87b6ae@1462439965@%3Coak-dev.jackrabbit.apache.org%3E
> [3]:
> https://lists.apache.org/thread.html/fbf28d5e864adbebd677a425cc915f89cbd7e0ef85a589fb4f948b51@1462784316@%3Coak-dev.jackrabbit.apache.org%3E
> [4]:
> https://lists.apache.org/thread.html/77b05609b7e6f0deedbd3282f734f8c606e6a7451db0698f29082d7b@1462891501@%3Coak-dev.jackrabbit.apache.org%3E
> [5]:
> https://lists.apache.org/thread.html/d8da865c1f971ff4c84c9616d9f09ea9369f3e0c6db20f98fbc6e4d3@%3Coak-dev.jackrabbit.apache.org%3E
> [6]:
> https://lists.apache.org/thread.html/ab1d405724674ef5855af0a0a9e87255d1144fe40762ff8e9d47@%3Coak-dev.jackrabbit.apache.org%3E
> [7]:
> https://lists.apache.org/thread.html/acc9eeef966916791c6073e76d3baa232f48abece4ae6b31f264a8ba@%3Coak-dev.jackrabbit.apache.org%3E
>

Re: OAK-4348 - intent to add oak-lucene-mt

[Tommaso Teofili]

I've realised we can actually name it oak-search-mt anyway, as we aim to
just implement existing SPIs / plugin; if they are the same or not it
doesn't make too much difference for the name itself.
I'll see if we can make FulltextQueryTermsProvider somehow work with Solr
in the context of OAK-3336 though, in the meantime I'll change the module
name into oak-search-mt.

Regards,
Tommaso


Il giorno ven 25 ago 2017 alle ore 10:02 Tommaso Teofili <
tommaso.teof...@gmail.com> ha scritto:

> yes, of course it can work the same way with the Solr index, provided we
> can generalize the FulltextQueryTermsProvider API in a way that avoids any
> additional network roundtrips (so it needs to be done before "sending" the
> query to Solr).
>
> In terms of backward compatibility we will need to see how to possibly
> keep the same package for FulltextQueryTermsProvider and make it available
> to Solr.
>
> Thanks,
> Tommaso
>
> Il giorno ven 25 ago 2017 alle ore 09:50 Chetan Mehrotra <
> chetan.mehro...@gmail.com> ha scritto:
>
>> This looks interesting!.
>>
>> Is this bound to Lucene or can possibly be used for Solr also (if we
>> generalize FulltextQueryTermsProvider concept). If yes then we can
>> name the module as oak-search-mt
>> Chetan Mehrotra
>>
>>
>> On Fri, Aug 25, 2017 at 1:14 PM, Tommaso Teofili
>> <tommaso.teof...@gmail.com> wrote:
>> > Hi all,
>> >
>> > as part of OAK-4348 [1] some time ago I had developed an extension in
>> > oak-lucene to expand search terms using machine translated term, in
>> order
>> > to provide cross language search capabilities to Oak (via
>> > FulltextQueryTermsProvider API [2]).
>> > In the context of a better modularized Oak, I was thinking to provide
>> such
>> > an extension as a separate module (e.g. called oak-lucene-mt), which
>> would
>> > be optional.
>> > In order to use it a language pack would need to be downloaded, for
>> example
>> > from [3].
>> > Please let me know if there's any concern or feedback.
>> >
>> > Regards,
>> > Tommaso
>> >
>> > [1] : https://issues.apache.org/jira/browse/OAK-4348
>> > [2] :
>> >
>> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/spi/FulltextQueryTermsProvider.java
>> > [3] : https://cwiki.apache.org/confluence/display/JOSHUA/Language+Packs
>>
>

Re: OAK-4348 - intent to add oak-lucene-mt

[Tommaso Teofili]

yes, of course it can work the same way with the Solr index, provided we
can generalize the FulltextQueryTermsProvider API in a way that avoids any
additional network roundtrips (so it needs to be done before "sending" the
query to Solr).

In terms of backward compatibility we will need to see how to possibly keep
the same package for FulltextQueryTermsProvider and make it available to
Solr.

Thanks,
Tommaso

Il giorno ven 25 ago 2017 alle ore 09:50 Chetan Mehrotra <
chetan.mehro...@gmail.com> ha scritto:

> This looks interesting!.
>
> Is this bound to Lucene or can possibly be used for Solr also (if we
> generalize FulltextQueryTermsProvider concept). If yes then we can
> name the module as oak-search-mt
> Chetan Mehrotra
>
>
> On Fri, Aug 25, 2017 at 1:14 PM, Tommaso Teofili
> <tommaso.teof...@gmail.com> wrote:
> > Hi all,
> >
> > as part of OAK-4348 [1] some time ago I had developed an extension in
> > oak-lucene to expand search terms using machine translated term, in order
> > to provide cross language search capabilities to Oak (via
> > FulltextQueryTermsProvider API [2]).
> > In the context of a better modularized Oak, I was thinking to provide
> such
> > an extension as a separate module (e.g. called oak-lucene-mt), which
> would
> > be optional.
> > In order to use it a language pack would need to be downloaded, for
> example
> > from [3].
> > Please let me know if there's any concern or feedback.
> >
> > Regards,
> > Tommaso
> >
> > [1] : https://issues.apache.org/jira/browse/OAK-4348
> > [2] :
> >
> https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/spi/FulltextQueryTermsProvider.java
> > [3] : https://cwiki.apache.org/confluence/display/JOSHUA/Language+Packs
>

OAK-4348 - intent to add oak-lucene-mt

[Tommaso Teofili]

Hi all,

as part of OAK-4348 [1] some time ago I had developed an extension in
oak-lucene to expand search terms using machine translated term, in order
to provide cross language search capabilities to Oak (via
FulltextQueryTermsProvider API [2]).
In the context of a better modularized Oak, I was thinking to provide such
an extension as a separate module (e.g. called oak-lucene-mt), which would
be optional.
In order to use it a language pack would need to be downloaded, for example
from [3].
Please let me know if there's any concern or feedback.

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/OAK-4348
[2] :
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/spi/FulltextQueryTermsProvider.java
[3] : https://cwiki.apache.org/confluence/display/JOSHUA/Language+Packs

Re: OAK-6575 - Provide a secure external URL to a DataStore binary.

[Tommaso Teofili]

Il giorno gio 24 ago 2017 alle ore 10:16 Michael Dürig 
ha scritto:

>
>
> On 24.08.17 09:27, Ian Boston wrote:
> > On 24 August 2017 at 08:18, Michael Dürig  wrote:
> >
> >>
> >>
> >> URI uri = ((OakValueFactory) valueFactory).getSignedURI(binProp);
> >>
> >>
> > +1
> >
> > One point
> > Users in Sling dont know abou Oak, they know about JCR.
> >
> > URI uri = ((OakValueFactory)
> > valueFactory).getSignedURI(jcrNode.getProperty("jcr:data"));
> >
> > No new APIs, let OakValueFactory work it out and return null if it cant
> do
> > it. It should also handle a null parameter.
> > (I assume OakValueFactory already exists)
>
> No, OakValueFactory does not exist as API (yet). But adding it would be
> more inline with how we approached the Oak API traditionally.
>
> I'm not against introducing the adaptable pattern but would like to
> understand whether there is concrete enough use cases beyond the current
> one to warrant it.
>

+1, currently I much prefer such a concrete approach over the adaptable;
not that it's bad per se, just I am not sure there'll be other use cases.

That said, although I understand the use cases and requirements, this still
seems to me a break into the fundamental Oak design, sorry.
It's not I'm totally against it, it's just that perhaps we should rethink
some of our design if it can't stick to our requirements, e.g. provide an
API for accessing binaries at the storage layer, which we expect to be used
by consumers having the right privileges by decorating it with something
similar to a JWT [1] token, emitted by the repo.

my 2 cents,
Tommaso

[1] : https://jwt.io/


>
> Michael
>
> >
> > If you want to make it extensible
> >
> >  T convertTo(Object source, Class target);
> >
> > used as
> >
> > URI uri = ((OakValueFactory)
> > valueFactory). convertTo(jcrNode.getProperty("jcr:data"), URI.class);
> >
> > The user doesnt know or need to know the URI is signed, it needs a URI
> that
> > can be resolved.
> > Oak wants it to be signed.
> >
> > Best Regards
> > Ian
> >
> >
> >
> >> Michael
> >>
> >>
> >>
> >>
> >>> A rough sketch of any alternative proposal would be helpful to decide
> >>> how to move forward
> >>>
> >>> Chetan Mehrotra
> >>>
> >>>
> >
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.6

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 22 ago 2017 alle ore 10:48 Michael Dürig 
ha scritto:

>
>
> On 22.08.17 08:52, Amit Jain wrote:
> > [x] +1 Release this package as Apache Jackrabbit Oak 1.7.6
>
> +1
>
> Michael
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.5

[Tommaso Teofili]

+1

Tommaso

Il giorno lun 31 lug 2017 alle ore 17:05 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 2017-07-31 15:43, Davide Giannella wrote:
> > ...
>
> [X] +1 Release this package as Apache Jackrabbit Oak 1.7.5
>

[jira] [Commented] (JCRVLT-196) Add remapping support for other than renames

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104737#comment-16104737
 ] 

Tommaso Teofili commented on JCRVLT-196:


bq. I thought I adjusted all the versions, it looks like you didn't take the 
latest changes.

that's weird, sorry. I thought I had taken the latest state ... 

bq. just out of curiosity, didn't you take 
https://patch-diff.githubusercontent.com/raw/apache/jackrabbit-filevault/pull/12.patch
 ?

I think I took 
https://github.com/apache/jackrabbit-filevault/compare/trunk...tripodsan:JCRVLT-196.patch

> Add remapping support for other than renames
> 
>
> Key: JCRVLT-196
> URL: https://issues.apache.org/jira/browse/JCRVLT-196
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Affects Versions: 3.1.40
>Reporter: Simone Tripodi
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
> Attachments: JCRVLT-196.patch
>
>
> In SLING-7017 we needed to add support to remap resources and thought VLT 
> APIs would have taken care of this, unfortunately we stumbled in the warning 
> message
> {noformat}
> remapping other than renames not supported yet
> {noformat}
> So the desired/expected action had no effect.
> Would it be possible to have it available? Is there any way to enable this 
> behaviour already?
> TIA!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-196) Add remapping support for other than renames

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104685#comment-16104685
 ] 

Tommaso Teofili commented on JCRVLT-196:


I've taken care of adjusting package export versions and committed it in 
r1803252.
[~tripod] if you think I've done anything wrong, feel free to revert / fix.

> Add remapping support for other than renames
> 
>
> Key: JCRVLT-196
> URL: https://issues.apache.org/jira/browse/JCRVLT-196
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Affects Versions: 3.1.40
>Reporter: Simone Tripodi
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
> Attachments: JCRVLT-196.patch
>
>
> In SLING-7017 we needed to add support to remap resources and thought VLT 
> APIs would have taken care of this, unfortunately we stumbled in the warning 
> message
> {noformat}
> remapping other than renames not supported yet
> {noformat}
> So the desired/expected action had no effect.
> Would it be possible to have it available? Is there any way to enable this 
> behaviour already?
> TIA!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (JCRVLT-196) Add remapping support for other than renames

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16104638#comment-16104638
 ] 

Tommaso Teofili commented on JCRVLT-196:


I did some tests and it seemed to work, therefore we can merge the PR (although 
I don't think I can directly merge from GH).

> Add remapping support for other than renames
> 
>
> Key: JCRVLT-196
> URL: https://issues.apache.org/jira/browse/JCRVLT-196
> Project: Jackrabbit FileVault
>  Issue Type: Improvement
>  Components: vlt
>Affects Versions: 3.1.40
>Reporter: Simone Tripodi
>Assignee: Tobias Bocanegra
> Fix For: 3.1.42
>
> Attachments: JCRVLT-196.patch
>
>
> In SLING-7017 we needed to add support to remap resources and thought VLT 
> APIs would have taken care of this, unfortunately we stumbled in the warning 
> message
> {noformat}
> remapping other than renames not supported yet
> {noformat}
> So the desired/expected action had no effect.
> Would it be possible to have it available? Is there any way to enable this 
> behaviour already?
> TIA!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.17

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 18 lug 2017 alle ore 13:29 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 2017-07-17 13:00, Davide Giannella wrote:
> > ...
>
> [X] +1 Release this package as Apache Jackrabbit Oak 1.4.17
>
> Best regards, Julian
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.4

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 19 lug 2017 alle ore 14:18 Andrei Dulceanu <
andrei.dulce...@gmail.com> ha scritto:

> [X] +1 Release this package as Apache Jackrabbit Oak 1.7.4
>
> Regards,
> Andrei
>
> 2017-07-19 14:00 GMT+03:00 Davide Giannella :
>
> >
> > A candidate for the Jackrabbit Oak 1.7.4 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.7.4/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> >
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.7.4/
> >
> > The SHA1 checksum of the archive is
> > 7d154255794da940e6866cbfd9deb844d2d04704.
> >
> > 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.7.4 7d154255794da940e6866cbfd9deb8
> > 44d2d04704
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.7.4.
> > 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.7.4
> > [ ] -1 Do not release this package because...
> >
> > D.
> >
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.7.3

[Tommaso Teofili]

+1

Tommaso

Il giorno lun 3 lug 2017 alle ore 17:20 Alex Deparvu 
ha scritto:

> +1
>
> On Mon, Jul 3, 2017 at 3:52 PM, Davide Giannella 
> wrote:
> > A candidate for the Jackrabbit Oak 1.7.3 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.7.3/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> >
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.7.3/
> >
> > The SHA1 checksum of the archive is
> > 837ca8a8d81877f74cd5f12f4eb7de0bebfcc262.
> >
> > 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.7.3
> 837ca8a8d81877f74cd5f12f4eb7de0bebfcc262
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.7.3.
> > 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.7.3
> > [ ] -1 Do not release this package because...
> >
> > Davide
> >
> >
> >
>

Re: [DiSCUSS] - highly vs rarely used data

[Tommaso Teofili]

I am sure there are both use cases for automatic vs manual/controlled
collection of unused data, however if I were a user I would personally not
want to care about this. While I'd be happy to know that my repo is faster
/ smaller / cleaner / whatever it'd sound overly complex to deal with JCR
and Oak constraints and behaviours from the application layer.
IMHO if we want to have such a feature in Oak to save resources, it should
be the persistence responsibility to say "hey, this content is not being
accessed for ages, let's try to claim some resources from it" (which could
mean moving to cold storage, compress it or anything else).

My 2 cents,
Tommaso



Il giorno lun 3 lug 2017 alle ore 15:46 Thomas Mueller
 ha scritto:

> Hi,
>
> > a property on the node, e.g. "archiveState=toArchive"
>
> I wonder if we _can_ easily write to the version store? Also, some
> nodetypes don't allow such properties? It might need to be a hidden
> property, but then you can't use the JCR API. Or maintain this data in a
> "shadow" structure (not with the nodes), which would complicate move
> operations.
>
> If I was a customer, I wouldn't wan't to *manually* mark / unmark binaries
> to be moved to / from long time storage. I would probably just want to rely
> on automatic management. But I'm not a customer, so my opinion is not that
> relevant (
>
> > Using a property directly specified for this purpose gives us more
> direct control over how it is being used I think.
>
> Sure, but it also comes with some complexities.
>
> Regards,
> Thomas
>
>
>
>

Re: [VOTE] Release Apache Jackrabbit Filevault 3.1.40

[Tommaso Teofili]

+1 (sigs check ok, build pass)

Tommaso

Il giorno dom 25 giu 2017 alle ore 09:26 Tobias Bocanegra 
ha scritto:

> here's my:
>
> +1 Release this package as Apache Jackrabbit Filevault 3.1.40
>
> (any one else care to vote?)
>
> regards, toby
>
> On Thu, Jun 22, 2017 at 6:27 PM, Marcel Reutegger 
> wrote:
> > On 22/06/17 04:14, Tobias Bocanegra wrote:
> >>
> >> Please vote on releasing this package as Apache Jackrabbit Filevault
> >> 3.1.40.
> >> The vote is open for the next 72 hours and passes if a majority of at
> >> least three +1 Jackrabbit PMC votes are cast.
> >
> >
> > All checks OK.
> >
> > +1 Release this package as Apache Jackrabbit Filevault 3.1.40
> >
> > Regards
> >  Marcel
>

[DiSCUSS] - highly vs rarely used data

[Tommaso Teofili]

Hi all,

recently I've been at a conference [1] where I attended an interesting
keynote about data management [2] (I think it refers to this 2016 paper
[3]).

Apart from the approaches proposed to solve the data management problem
(e.g. get rid of DBMSs!) I got interested in the discussion about how we
deal with the increasing amount of data that we have to manage (also
because of some issues we have [4]).
In many systems only a very small subset of the data is used because the
amount of information users really need refers only to most recently
ingested data (e.g. social networks); while that doesn't always apply for
content repositories in general (e.g. if you build a CMS on top of it) I
think it's interesting to think about whether we can optimize our
persistence layer to work better with highly used data (e.g. more recent)
and use less space/cpu for data that is used more rarely.

For example, putting this together with the incremental indexing section of
the paper [3] I was thinking (but that's already a solution rather than
"just" a discussion) perhaps we could simply avoid indexing *some* content
until it's needed (e.g. the first time you get traversal, then index so
that next query over same data will be faster) but that's just an example.

What do others think ?
Regards,
Tommaso

[1] : http://www.iccs-meeting.org/iccs2017/
[2] : http://www.iccs-meeting.org/iccs2017/keynote-lectures/#Ailamaki
[3] : https://infoscience.epfl.ch/record/219993/files/p12-pavlovic.pdf
[4] : https://issues.apache.org/jira/browse/OAK-5192

backporting OAK-6317 until 1.2 branch

[Tommaso Teofili]

Hi all,

I'd like to backport the fix for a bug in LMSEstimator [1] (LMSEstimator is
used by oak-solr-core to estimate the no. of entries in the index without
issuing a query to Solr) until branch 1.2 (as it was observed on a 1.2.x
Oak instance).

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/OAK-6317

Re: Oak indexes

[Tommaso Teofili]

Hi Roy,

if you have copy on read enabled (it is by default) for the Oak Lucene
index you should be able to take the index at their paths on the file
systems and use Luke as per any other Lucene index (btw Oak is currently
using Lucene 4.7.1).

Hope it helps,
Tommaso

[1] : http://jackrabbit.apache.org/oak/docs/query/lucene.html#CopyOnRead

Il giorno lun 8 mag 2017 alle ore 15:01 Roy Teeuwen  ha
scritto:

> Hey all,
>
> I got a question relating the oak:indexes in Jackrabbit OAK. Is it
> possible to actually open these indexes and see what is inside them? I know
> it is possible to use Luke to open a Lucene index and query it manually, is
> this also possible for the property index and the Lucene index inside oak?
> If so, how would I go about this, where are they situated on file system so
> that I could open them with Luke or something
>
> Thanks!
> Roy
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.25

[Tommaso Teofili]

+1, all checks ok.

Regards,
Tommaso

Il giorno mar 11 apr 2017 alle ore 11:30 Marcel Reutegger <
mreut...@adobe.com> ha scritto:

> On 11/04/17 07:51, Amit Jain wrote:
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.2.25.
> > The vote is open for the next 72 hours and passes if a majority of at
> > least three +1 Jackrabbit PMC votes are cast.
>
> All checks OK.
>
> +1 Release this package as Apache Jackrabbit Oak 1.2.25
>
> Regards
>   Marcel
>

Re: [m12n] remove oak-core dep in oak-blob-*

[Tommaso Teofili]

yes, sorry, my bad for not having provided the right context.

in such context oak-commons would contain plain utility class which are not
oak specific (no dependency on org.apache.jackrabbit.oak..) while oak-base
would contain utility classes that relate to oak specific stuff.

Regards,
Tommaso

Il giorno gio 6 apr 2017 alle ore 15:16 Angela Schreiber <anch...@adobe.com>
ha scritto:

> hi davide
>
> actually we don't have oak-base :-)
> the mail might be a bit out of context... we only have it in a poc.
>
> you may want to take a look at that initial draft
> https://github.com/mreutegg/jackrabbit-oak/tree/m12n
> but please note that it is still heavily under construction... basically
> we just want to see how far we get with some limited effort.
>
> angela
>
>
>
>
> On 06/04/17 15:09, "Davide Giannella" <dav...@apache.org> wrote:
>
> >On 06/04/2017 11:11, Tommaso Teofili wrote:
> >> (and eventually oak-commons / oak-base)
> >
> >I wasn't aware of oak-base. What about a bundle oak-api which exports
> >the APIs on which other bundles should rely on?
> >
> >D.
> >
> >
>
>

[m12n] remove oak-core dep in oak-blob-*

[Tommaso Teofili]

Hi all,

as part of refactoring and making more appropriate interdependencies I
think it'd be good if we could have that oak-blob-* modules depend on just
oak-blob (and eventually oak-commons / oak-base) and cut their dependency
to oak-core so that they would only rely on the purposely exposed
blob/datastore specific APIs.

WDYT?

Regards,
Tommaso

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.38

[Tommaso Teofili]

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

all checks pass.
Regards,
Tommaso

Il giorno mar 28 mar 2017 alle ore 15:13 Alex Parvulescu <
alex.parvule...@gmail.com> ha scritto:

>  [X] +1 Release this package as Apache Jackrabbit Oak 1.0.38
>
> all checks ok,
>
> alex
>
>
> On Tue, Mar 28, 2017 at 2:33 PM, Dominique Jaeggi  wrote:
>
> > A candidate for the Jackrabbit Oak 1.0.38 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.38/
> >
> > The release candidate is a zip archive of the sources in:
> >
> > https://svn.apache.org/repos/asf/jackrabbit/oak/tags/
> > jackrabbit-oak-1.0.38/
> >
> > The SHA1 checksum of the archive is
> > f5e8e98900f2464d84d730551f6d30c309155aa5.
> >
> > 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.0.38 f5e8e98900f2464d84d730551f6d30
> > c309155aa5
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.38.
> > 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.0.38
> >
> > [ ] -1 Do not release this package because...
> >
> > My vote is +1.
> >
> > Thanks
> > dom.
> >
>

Re: problem on oak jcr sql2 query

[Tommaso Teofili]

Hi Francesco,

do you have other indexes within your Oak repo ?
It might be that the query engine selects a different index which only acts
on [nt:file] nodes.
You can try checking the plan [1] for your query and compare with the
[nt:base] version.
It might also be useful to enable debug logging
for org.apache.jackrabbit.oak.query, that will allow you to check the costs
associated to each index so that it should be easier to eventually tweak
the index definitions accordingly (note that the query engine selects the
index with the lowest cost), e.g. you should see something like:
...
cost for solr is 1.4
cost for lucene is 1.2
cost for reference is Infinity
...


Regards,
Tommaso

[1] :
http://jackrabbit.apache.org/oak/docs/query/query-troubleshooting.html#Query_Plan


Il giorno mar 28 mar 2017 alle ore 12:28 Ancona Francesco <
francesco.anc...@siav.it> ha scritto:

> We have wrapped oak jcr implementation with our data model, so it's not so
> easy give you our unit test (our sw is not yet open sourece :-))
> Besides we know the documenti is correctly indexed, cause we see it in
> solr; so you can use any type of pdf: oak manage full text correctly.
>
> Anyway we tried to use a query like this to optimize performance:
> SELECT parent.* FROM [nt:file] AS parent INNER JOIN [nt:resource] AS child
> ON ISCHILDNODE(child,parent) WHERE CONTAINS(child.*, ' company') or
> CONTAINS(parent.*, ' company')
>
> But we saw that index planner doesn't permit solr query (oak doesn't use
> solr for the query). So we can't find words inside content (nt:resource)
>
> What is wrong ?
> Why oak doesn't use solr for full text query ?
>
> Thanks in advance,
> best regards
>
> -Messaggio originale-
> Da: Tommaso Teofili [mailto:tomm...@apache.org]
> Inviato: martedì 28 marzo 2017 10:33
> A: oak-dev@jackrabbit.apache.org
> Cc: Diquigiovanni Simone <simone.diquigiova...@siav.it>
> Oggetto: Re: problem on oak jcr sql2 query
>
> Hi Francesco,
>
> Il giorno lun 27 mar 2017 alle ore 08:59 Ancona Francesco <
> francesco.anc...@siav.it> ha scritto:
>
> Sorry.
>
> We are using Oak 1.4.10 and solr 4.10.4
>
> i send you also a pdf example: the searched word is "sezione"
>
>
> attachments do not usually get through the mailing list therefore we can't
> look into it.
>
>
>
> In another document ([nt:file] that doesn't have childs) i'd want match
> only through metadata that contains the word "company"
>
> Actually  i resolved the problem executing a query like this: select p.*
> from [nt:base] as p where .. contains (p.*, "company") or contains
> (p.*, "sezione")
>
> Then i explore (programmatically and after the query response) jcr nodes
> to set only nodes that are [nt:file]
>
> Is it the correct approach ?
>
>
> this can work but it's surely worse in terms of performance as you
> retrieve and skip some docs you don't really need.
> If you can provide the PDF via a link or, better, a unit test we can
> probably help you more effectively.
>
> Regards,
> Tommaso
>
>
>
> Thanks in advance,
> best regards
>
> -Messaggio originale-
> Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
> Inviato: venerdì 24 marzo 2017 14:56
> A: oak-dev@jackrabbit.apache.org
> Cc: Diquigiovanni Simone <simone.diquigiova...@siav.it>
> Oggetto: Re: problem on oak jcr sql2 query
>
> It'd be helpful to also know the version of Oak and Solr you're using and,
> possibly, sample content you expect the query to match.
>
> Thanks,
> Tommaso
>
>
> Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller <muel...@adobe.com>
> ha scritto:
>
> > Could you post the index definition please?
> >
> >
> > From: Ancona Francesco <francesco.anc...@siav.it>
> > Reply-To: "oak-dev@jackrabbit.apache.org"
> > <oak-dev@jackrabbit.apache.org>
> > Date: Thursday, 23 March 2017 at 15:19
> > To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
> > Cc: Diquigiovanni Simone <simone.diquigiova...@siav.it>
> > Subject: problem on oak jcr sql2 query
> >
> > Hi all,
> > we use SolrSrerver for fulltext searches; both on metadata both on
> > content binary.
> > In general i have to find all nodes nt:file that contain the word
> > “company” or all nodes that have childs nt:resource that contain the
> > same word.
> >
> > Unfortunately if upload e file (so a node that is a nt:resource) and i
> > use this query SELECT p.* FROM [nt:file] as p where
> > contains(p.*,''company ')
> >
> > Solr find result  but the RowIterator doesn’t return anything.
> >
> > I

Re: problem on oak jcr sql2 query

[Tommaso Teofili]

Hi Francesco,

Il giorno lun 27 mar 2017 alle ore 08:59 Ancona Francesco <
francesco.anc...@siav.it> ha scritto:

Sorry.

We are using Oak 1.4.10 and solr 4.10.4

i send you also a pdf example: the searched word is "sezione"


attachments do not usually get through the mailing list therefore we can't
look into it.



In another document ([nt:file] that doesn't have childs) i'd want match
only through metadata that contains the word "company"

Actually  i resolved the problem executing a query like this: select p.*
from [nt:base] as p where .. contains (p.*, "company") or contains
(p.*, "sezione")

Then i explore (programmatically and after the query response) jcr nodes to
set only nodes that are [nt:file]

Is it the correct approach ?


this can work but it's surely worse in terms of performance as you retrieve
and skip some docs you don't really need.
If you can provide the PDF via a link or, better, a unit test we can
probably help you more effectively.

Regards,
Tommaso



Thanks in advance,
best regards

-----Messaggio originale-
Da: Tommaso Teofili [mailto:tommaso.teof...@gmail.com]
Inviato: venerdì 24 marzo 2017 14:56
A: oak-dev@jackrabbit.apache.org
Cc: Diquigiovanni Simone <simone.diquigiova...@siav.it>
Oggetto: Re: problem on oak jcr sql2 query

It'd be helpful to also know the version of Oak and Solr you're using and,
possibly, sample content you expect the query to match.

Thanks,
Tommaso


Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller <muel...@adobe.com>
ha scritto:

> Could you post the index definition please?
>
>
> From: Ancona Francesco <francesco.anc...@siav.it>
> Reply-To: "oak-dev@jackrabbit.apache.org"
> <oak-dev@jackrabbit.apache.org>
> Date: Thursday, 23 March 2017 at 15:19
> To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
> Cc: Diquigiovanni Simone <simone.diquigiova...@siav.it>
> Subject: problem on oak jcr sql2 query
>
> Hi all,
> we use SolrSrerver for fulltext searches; both on metadata both on
> content binary.
> In general i have to find all nodes nt:file that contain the word
> “company” or all nodes that have childs nt:resource that contain the
> same word.
>
> Unfortunately if upload e file (so a node that is a nt:resource) and i
> use this query SELECT p.* FROM [nt:file] as p where
> contains(p.*,''company ')
>
> Solr find result  but the RowIterator doesn’t return anything.
>
> Instead the above query works
> SELECT p.* FROM [nt:resource] as p where contains(p.*,'company') But
> doesn’t find nt:file nodes
>
> Can you help me ?
>
> Thanks in advance.
>
>
> [cid:image002.png@01D2A3E8.D7747740]
> Francesco Ancona | Software Dev. Dept. (SP) - Software Architect tel.
> +39 049 8979797 <049%20897%209797> <049%20897%209797> | fax +39 049
8978800 <049%20897%208800>
> <049%20897%208800> | cel. +39 3299060325 <329%20906%200325>
<329%20906%200325>
> e-mail: francesco.anc...@siav.it | www.siav.it<
> https://na01.safelinks.protection.outlook.com/?url=www.siav.it=02
> %7C01%7C%7Caed3cadf483741e2971708d471f7b284%7Cfa7b1b5a7b34438794aed2c1
> 78decee1%7C0%7C0%7C636258756051666135=GFXjC%2BgyoIh37AXmGYhYdORt
> Xp1dFiA5v0hoghgbtBw%3D=0
> >
>
> I contenuti di questa e-mail e dei suoi allegati sono confidenziali e
> riservati esclusivamente ai destinatari.
> L'utilizzo per qualunque fine del presente messaggio e degli allegati
> così come la relativa divulgazione senza l'autorizzazione del mittente
> sono vietati.
> Se avete ricevuto questa e-mail per errore, vi preghiamo di
> distruggerla e di comunicarcelo.
> I dati personali sono trattati esclusivamente per le finalità della
> presente comunicazione in conformità con la legislazione vigente (D.lgs.
> 196/2003 "Codice Privacy").
> Per informazioni: SIAV S.p.A. – s...@siav.it – 049 8979797
<049%20897%209797>
> <049%20897%209797>
>
> The contents of this e-mail and its attachments are confidential and
> reserved exclusively to the recipients.
> The use for any purpose of this message and attachments as well as its
> disclosure without the consent of the sender is prohibited.
> If you have received this email in error, please destroy it and notify us.
> Personal data shall be processed solely for the purposes of this
> notice in accordance with current legislation (Legislative Decree no.
> 196/2003 "Code").
> For more information: SIAV S.p.A. – s...@siav.it – 049 8979797
<049%20897%209797>
> <049%20897%209797>
>
>




This footnote confirms that this email message has been scanned by PineApp
Mail-SeCure for the presence of malicious code, vandals & computer viruses.

Re: problem on oak jcr sql2 query

[Tommaso Teofili]

It'd be helpful to also know the version of Oak and Solr you're using and,
possibly, sample content you expect the query to match.

Thanks,
Tommaso


Il giorno ven 24 mar 2017 alle ore 14:54 Thomas Mueller 
ha scritto:

> Could you post the index definition please?
>
>
> From: Ancona Francesco 
> Reply-To: "oak-dev@jackrabbit.apache.org" 
> Date: Thursday, 23 March 2017 at 15:19
> To: "oak-dev@jackrabbit.apache.org" 
> Cc: Diquigiovanni Simone 
> Subject: problem on oak jcr sql2 query
>
> Hi all,
> we use SolrSrerver for fulltext searches; both on metadata both on content
> binary.
> In general i have to find all nodes nt:file that contain the word
> “company” or all nodes that have childs nt:resource that contain the same
> word.
>
> Unfortunately if upload e file (so a node that is a nt:resource) and i use
> this query
> SELECT p.* FROM [nt:file] as p where contains(p.*,''company ')
>
> Solr find result  but the RowIterator doesn’t return anything.
>
> Instead the above query works
> SELECT p.* FROM [nt:resource] as p where contains(p.*,'company')
> But doesn’t find nt:file nodes
>
> Can you help me ?
>
> Thanks in advance.
>
>
> [cid:image002.png@01D2A3E8.D7747740]
> Francesco Ancona | Software Dev. Dept. (SP) - Software Architect
> tel. +39 049 8979797 <049%20897%209797> | fax +39 049 8978800
> <049%20897%208800> | cel. +39 3299060325 <329%20906%200325>
> e-mail: francesco.anc...@siav.it | www.siav.it<
> https://na01.safelinks.protection.outlook.com/?url=www.siav.it=02%7C01%7C%7Caed3cadf483741e2971708d471f7b284%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636258756051666135=GFXjC%2BgyoIh37AXmGYhYdORtXp1dFiA5v0hoghgbtBw%3D=0
> >
>
> I contenuti di questa e-mail e dei suoi allegati sono confidenziali e
> riservati esclusivamente ai destinatari.
> L'utilizzo per qualunque fine del presente messaggio e degli allegati così
> come la relativa divulgazione senza l'autorizzazione del mittente sono
> vietati.
> Se avete ricevuto questa e-mail per errore, vi preghiamo di distruggerla e
> di comunicarcelo.
> I dati personali sono trattati esclusivamente per le finalità della
> presente comunicazione in conformità con la legislazione vigente (D.lgs.
> 196/2003 "Codice Privacy").
> Per informazioni: SIAV S.p.A. – s...@siav.it – 049 8979797
> <049%20897%209797>
>
> The contents of this e-mail and its attachments are confidential and
> reserved exclusively to the recipients.
> The use for any purpose of this message and attachments as well as its
> disclosure without the consent of the sender is prohibited.
> If you have received this email in error, please destroy it and notify us.
> Personal data shall be processed solely for the purposes of this notice in
> accordance with current legislation (Legislative Decree no. 196/2003
> "Code").
> For more information: SIAV S.p.A. – s...@siav.it – 049 8979797
> <049%20897%209797>
>
>

Re: Merge policy for the 1.6 branch

[Tommaso Teofili]

ok, persistent and impacting all branches, sounds good to me.

Regards,
Tommaso

Il giorno mar 14 mar 2017 alle ore 12:20 Michael Dürig <mdue...@apache.org>
ha scritto:

>
> I would be in favour to generally apply this policy for all branches as
> with the number of branches we have now it is too easy to miss something
> by just following @commits.
>
> Michael
>
> On 14.03.17 12:07, Tommaso Teofili wrote:
> > I have one concern: is such a backport policy meant to be time boxed
> (e.g.
> > keep it for first N 1.6.x releases)?
> > I am asking this because I'm wondering if we want to establish this
> policy
> > for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim
> to
> > be a bit conservative in the first months of a 1.x release and move back
> to
> > a less strict merge policy for backports afterwards.
> >
> > Regards,
> > Tommaso
> >
> > Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig <
> mdue...@apache.org>
> > ha scritto:
> >
> >>
> >> Hi,
> >>
> >> Following up on Davide's release plan for Oak 1.6 [1] we should define a
> >> merge policy for the 1.6 branch. I would suggest to be a bit more
> >> conservative here than we have been in the past and ask for reviews of
> >> backports. That is, announce candidates on @oak-dev mentioning the issue
> >> reference, potential risks, mitigations, etc. I don't think we need to
> >> block the actual backport being performed on the outcome of the review
> >> as in the worst case changes can always be reverted. The main aim of the
> >> announcement should be to increase visibility of the backports and
> >> ensure they are eventually reviewed.
> >>
> >> In short, announce your backport on @oak-dev and ask for review. If
> >> confident enough that the review will pass anyway, go ahead but be
> >> prepared to revert.
> >>
> >> I think this is what we informally did so far already but wanted to
> >> state this a bit more explicitly.
> >>
> >> WDYT?
> >>
> >> Michael
> >>
> >>
> >>
> >> [1]
> >>
> >>
> https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
> >>
> >
>

Re: Merge policy for the 1.6 branch

[Tommaso Teofili]

I have one concern: is such a backport policy meant to be time boxed (e.g.
keep it for first N 1.6.x releases)?
I am asking this because I'm wondering if we want to establish this policy
for all backports (1.4, 1.2, 1.0 branches too), or alternatively we aim to
be a bit conservative in the first months of a 1.x release and move back to
a less strict merge policy for backports afterwards.

Regards,
Tommaso

Il giorno mar 14 mar 2017 alle ore 11:59 Michael Dürig 
ha scritto:

>
> Hi,
>
> Following up on Davide's release plan for Oak 1.6 [1] we should define a
> merge policy for the 1.6 branch. I would suggest to be a bit more
> conservative here than we have been in the past and ask for reviews of
> backports. That is, announce candidates on @oak-dev mentioning the issue
> reference, potential risks, mitigations, etc. I don't think we need to
> block the actual backport being performed on the outcome of the review
> as in the worst case changes can always be reverted. The main aim of the
> announcement should be to increase visibility of the backports and
> ensure they are eventually reviewed.
>
> In short, announce your backport on @oak-dev and ask for review. If
> confident enough that the review will pass anyway, go ahead but be
> prepared to revert.
>
> I think this is what we informally did so far already but wanted to
> state this a bit more explicitly.
>
> WDYT?
>
> Michael
>
>
>
> [1]
>
> https://lists.apache.org/thread.html/e5e71b61de9612d7cac195cbe948e8bdca58ee38ee16e7f124ea742c@%3Coak-dev.jackrabbit.apache.org%3E
>

[jira] [Commented] (JCR-4115) Don't use SHA-1 for new DataStore binaries (Jackrabbit)

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882315#comment-15882315
 ] 

Tommaso Teofili commented on JCR-4115:
--

bq. Not sure if AbstractDataStore.HmacSHA1 is also affected or not.

I'm not sure either (probably not), in case we would need to have ADS work on 
both algos (HmacSHA1 and e.g. HmacSHA256).

> Don't use SHA-1 for new DataStore binaries (Jackrabbit)
> ---
>
> Key: JCR-4115
> URL: https://issues.apache.org/jira/browse/JCR-4115
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>Reporter: Thomas Mueller
> Attachments: JCR-4115.patch
>
>
> A collision for SHA-1 has been published. We still use SHA-1 for the 
> FileDataStore, and I believe the S3 DataStore right now. Given there is a 
> collision, we should switch to a stronger algorithm, for example SHA-256, for 
> new binaries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Release plan Oak 1.4.13

[Tommaso Teofili]

I've backported those issues, thanks Amit for having waited for me.

Regards,
Tommaso

Il giorno lun 6 feb 2017 alle ore 11:23 Tommaso Teofili <
tommaso.teof...@gmail.com> ha scritto:

> thanks a lot Amit, sounds good
>
> Regards,
> Tommaso
>
> Il giorno lun 6 feb 2017 alle ore 10:22 Amit Jain <am...@ieee.org> ha
> scritto:
>
> I'll postpone the release for tomorrow (7th February) to get these fixes
> in.
> @Tommaso let me know if that's ok or you would need more time.
>
> Thanks
> Amit
>
> On Fri, Feb 3, 2017 at 4:34 PM, Tommaso Teofili <tomm...@apache.org>
> wrote:
>
> > yes, I should be able to fix them by that date.
> >
> > Thanks,
> > Tommaso
> >
> > Il giorno ven 3 feb 2017 alle ore 11:56 Davide Giannella <
> > dav...@apache.org>
> > ha scritto:
> >
> > > On 03/02/2017 03:41, Amit Jain wrote:
> > > > Hi Team,
> > > >
> > > > Oak 1.4.13 release is scheduled for Monday (6th February) as planned.
> > If
> > > > there's something that needs to be put in urgently let me know.
> > > >
> > > > Thanks
> > > > Amit
> > > >
> > > We may have to wait for
> > >
> > > https://issues.apache.org/jira/browse/OAK-4922
> > > https://issues.apache.org/jira/browse/OAK-5536
> > >
> > > @Tommaso will 6th/Feb be sufficient for you to complete these two?
> > >
> > > Cheers
> > > Davide
> > >
> > >
> > >
> >
>
>

Re: Release plan Oak 1.4.13

[Tommaso Teofili]

thanks a lot Amit, sounds good

Regards,
Tommaso

Il giorno lun 6 feb 2017 alle ore 10:22 Amit Jain <am...@ieee.org> ha
scritto:

> I'll postpone the release for tomorrow (7th February) to get these fixes
> in.
> @Tommaso let me know if that's ok or you would need more time.
>
> Thanks
> Amit
>
> On Fri, Feb 3, 2017 at 4:34 PM, Tommaso Teofili <tomm...@apache.org>
> wrote:
>
> > yes, I should be able to fix them by that date.
> >
> > Thanks,
> > Tommaso
> >
> > Il giorno ven 3 feb 2017 alle ore 11:56 Davide Giannella <
> > dav...@apache.org>
> > ha scritto:
> >
> > > On 03/02/2017 03:41, Amit Jain wrote:
> > > > Hi Team,
> > > >
> > > > Oak 1.4.13 release is scheduled for Monday (6th February) as planned.
> > If
> > > > there's something that needs to be put in urgently let me know.
> > > >
> > > > Thanks
> > > > Amit
> > > >
> > > We may have to wait for
> > >
> > > https://issues.apache.org/jira/browse/OAK-4922
> > > https://issues.apache.org/jira/browse/OAK-5536
> > >
> > > @Tommaso will 6th/Feb be sufficient for you to complete these two?
> > >
> > > Cheers
> > > Davide
> > >
> > >
> > >
> >
>

Re: Release plan Oak 1.4.13

[Tommaso Teofili]

yes, I should be able to fix them by that date.

Thanks,
Tommaso

Il giorno ven 3 feb 2017 alle ore 11:56 Davide Giannella 
ha scritto:

> On 03/02/2017 03:41, Amit Jain wrote:
> > Hi Team,
> >
> > Oak 1.4.13 release is scheduled for Monday (6th February) as planned. If
> > there's something that needs to be put in urgently let me know.
> >
> > Thanks
> > Amit
> >
> We may have to wait for
>
> https://issues.apache.org/jira/browse/OAK-4922
> https://issues.apache.org/jira/browse/OAK-5536
>
> @Tommaso will 6th/Feb be sufficient for you to complete these two?
>
> Cheers
> Davide
>
>
>

Re: Hybrid indexing and soft commits.

[Tommaso Teofili]

+1

Tommaso

Il giorno ven 18 nov 2016 alle ore 11:06 Ian Boston  ha
scritto:

> Hi,
> IIUC the Hybrid indexing on the master operates in parallel with the master
> index writer, performing the same task but repeatedly throwing its work
> away when the master provides an update. IIUC, it effectively performs many
> soft commits to achieve NRT behaviour.
>
> I wonder if there is an opportunity to use the Hybrid indexer on the master
> instance and every n seconds (or even minutes) perform a hard commit. That
> hard commit being the output of the master index writer, committed by Oak
> to the DS. This would avoid doing the work and follows the pattern used by
> Solr and ES, where an indexing update is written to a WAL, soft committed
> and periodically hard committed. The WAL comes free as part of Oak so if
> the soft commits are lost, the index and WAL starts from the last hard
> commit.
>
> To be clear. I am only talking about de-duplicating the effort performed on
> the master node by the hybrid indexer and the master index writer. I am not
> talking about anything performed on slave index reader instances which also
> have a hybrid indexer. Those hybrid indexers will still work as they do
> now.
>
> wdyt?
> Best Regards
> Ian
>

Re: RIP Apache Jenkins!?

[Tommaso Teofili]

sorry but I disagree, while Adobe can have its internal infrastructure run
whatever kind of tests, I think Oak should have its own continuous build
working on the ASF infra, if anything needs to be adjusted we can get in
touch with infra@.
Other than that I am sorry I could not spend more time on CI setup (and Oak
in general) lately.

Regards,
Tommaso

Il giorno gio 17 nov 2016 alle ore 13:35 Michael Dürig 
ha scritto:

>
>
> On 17.11.16 12:31 , Bertrand Delacretaz wrote:
> > On Thu, Nov 17, 2016 at 9:27 AM, Michael Dürig 
> wrote:
> >> ...I was mostly thinking of using some internal resources as so far the
> public
> >> options didn't work out for us...
> >
> > Internal to what?
>
> To Adobe
>
> Michael
> >
> > -Bertrand
> >
>

Re: segment-tar depending on oak-core

[Tommaso Teofili]

Il giorno ven 21 ott 2016 alle ore 16:08 Thomas Mueller 
ha scritto:

> Hi,
>
> >The release process in Oak is a joke.
>
> I don't think it's a joke.
>
> > Releasing every two weeks by
> >using version numbers as counters just for the sake of it is
> >embarrassing.
>
> Why? It's simple.
>
> > I don't even know how many releases of our parent POM we
> >have, every one of them equal to the other, and this is nonsense.
>
> "Nonsense"... again a word without explanation.
>

my understanding of it is that probably it doesn't make much sense to
release every time a new version of oak-parent that doesn't contain
anything new.


>
> >We shouldn't go backward, but forward.
>
> It depends on what "backward is". I would prefer if we make things
> "simpler".
>
> > We need to extract APIs into
> >their own independently released bundles.
>
> I don't think we need to do that. The "release everything at once" sounds
> good to me.
>
> > We should split oak-run in
> >different CLI utility modules
>
> Split, split, and again split. Why? What is the advantage?
>
> >, so that every implementation can take
> >better care of their own utilities.
>
> It's the Oak utilities. I think the current organization is just fine.
>
> >Oak is not a pet project
>
> Again, you are using strong words ("pet"), but without real explanation...
> How is it that your definition of "pet" is the only valid one?
>
> >and we
> >have to admit that its current level of complexity doesn't allow us to
> >use oak-core and oak-run as dumping grounds anymore.
>
> Again a strong word... "dump".
>
> I just don't see how making tiny "ravioli" modules makes things any
> better.


sorry, as an Italian I need a clarification on this (ravioli architecture,
nice sounding).


> It surely makes things more complex, as we see with
> oak-segment-tar: it forces to add even more and more modules, to be able
> to deal with the consequences of adding modules.
>

In my opinion what we're discussing is our view on how Oak should be
architectured, either as a big (layered) blackbox or as a set of reusable
(and interoperable) software components.
The "release all at once with version x.y" approach sounds to me more
inline with the former while the "release every module separately and
abstract APIs as much as possible" sounds more inline with the latter.

My 2 cents,
Tommaso


>
> Regards,
> Thomas
>
>

Re: OAK/AEM-SOLR indexing

[Tommaso Teofili]

Hi Sri,

in this mailing list we only discuss development concerns that relate to
pure Oak, AEM specific questions should go through other (Adobe) channels.
The current way Solr index can filter content is by whitelisting /
blacklisting properties [1]; that is you compile a list of properties
(whitelist) that should be indexed (all the other properties will never be
indexed), or a list of properties (blacklist) that should not be indexed
(all the other properties will be indexed).
If you have any requirements that you think could be helpful in certain use
cases, feel free to discuss it here and / or open a Jira issue.

Regards,
Tommaso

[1] : http://jackrabbit.apache.org/oak/docs/query/solr.html


Il giorno dom 16 ott 2016 alle ore 14:02 sri vaths
 ha scritto:

> Hi,
>
> Need to know is there a way to tell OOTB OAK/AEM-SOLR indexing to send
> only the Activated content/nodes for indexing rather sending all the
> edits/updates to SOLR index
>
> Option1If any OOTB OAK-SOLR configs ?
> orOption2if not OOTB - Is there a way to plug an SOLRIndexEditior
> pre-processor to SolrIndexEditor to do the above ?Also if any pre-processor
> before sending to SOLR please share if API usages?
> orOption3is it a recommended approach to deploy OOTB OAK/AEM SOLR indexing
> on publish instances rather author - at least on 1 publish instances
> We are using AEM 6.1 and hence Apache Jackrabbit Oak 1.2.
>
> with regardsSri
>
> On Friday, 2 September 2016 10:09 AM, sri vaths 
> wrote:
>
>
>  Hi,
> Just need to know is there a way to tell OOTB OAK/AEM-SOLR indexing to
> send only the Activated content/nodes for indexing rather sending all the
> edits/updates to SOLR index
>
> Option1If any OOTB OAK-SOLR configs ?
> orOption2if not OOTB - Is there a way to plug an SOLRIndexEditior
> pre-processor to SolrIndexEditor to do the above ?
> orOption3Are is it a recommended approach to deploy OOTB OAK/AEM SOLR
> indexing on publish instances rather author - at least on 1 publish
> instances
> We are using AEM 6.1 and hence Apache Jackrabbit Oak 1.2.
> with regardsSri
>
>

[jira] [Commented] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15567945#comment-15567945
 ] 

Tommaso Teofili commented on JCRVLT-128:


thanks [~tri...@apache.org] for your help.

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
>Assignee: Tobias Bocanegra
> Fix For: 3.1.32
>
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15532185#comment-15532185
 ] 

Tommaso Teofili commented on JCRVLT-128:


the reason why I had thought it is for REPLACE is that I see the special 
handling is guarded by _if (wspFilter.getImportMode(path) == 
ImportMode.REPLACE)_. However I agree we need a test in order to fix and guard 
from any regression there.

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
>Assignee: Tobias Bocanegra
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529500#comment-15529500
 ] 

Tommaso Teofili commented on JCRVLT-128:


[~tri...@apache.org] that fix doesn't seem to help, as the problem on the 
importer side is with _UPDATE_ ImportMode. Do you think your changes make sense 
for that case too ?

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
>Assignee: Tobias Bocanegra
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509810#comment-15509810
 ] 

Tommaso Teofili edited comment on JCRVLT-128 at 9/21/16 1:19 PM:
-

attaching dummy patch which avoids restoring _rep:cache_ nodes from stashed 
ones in {{JcrSysViewTransformer}}; so the side effect is that the cache nodes 
are removed after package installation.

[~tripod] WDYT? I'm pretty sure there's a better way of doing that.


was (Author: teofili):
attaching dummy patch which avoids restoring _rep:cache_ nodes from stashed 
ones in {{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a 
better way of doing that.

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509810#comment-15509810
 ] 

Tommaso Teofili edited comment on JCRVLT-128 at 9/21/16 1:10 PM:
-

attaching dummy patch which avoids restoring _rep:cache_ nodes from stashed 
ones in {{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a 
better way of doing that.


was (Author: teofili):
attaching dummy patch which avoids adding _rep:cache_ in 
{{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a better way 
of doing that.

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated JCRVLT-128:
---
Attachment: JCRVLT-128.0.patch

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated JCRVLT-128:
---
Attachment: (was: JCRVLT-128.0.patch)

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated JCRVLT-128:
---
Attachment: JCRVLT-128.0.patch

attaching dummy patch which avoids adding _rep:cache_ in 
{{JcrSysViewTransformer}}, [~tripod] WDYT? I'm pretty sure there's a better way 
of doing that.

> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
> Attachments: JCRVLT-128.0.patch
>
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node if ImportMode is set to 
> UPDATE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
>   at 
> org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
>   at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
>   at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
>   at 
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated JCRVLT-128:
---
Description: 
In OAK-3003 a persisted [principal 
cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] was 
introduced that creates _rep:cache_ nodes under authorizables.
Creating a package for such authorizables will result in including the cache 
node in there, which sounds wrong as that node is an implementation detail 
which doesn't make sense to install anywhere; however that can be avoided by 
proper filters.
What is problematic is the installation phase, if an authorizable gets packaged 
with FileVault (no rep:cache in the package) and the target user/group has a 
rep:cache node itself the importer will try (and fail as it's protected) to 
delete the persisted cache node if ImportMode is set to UPDATE.
In my opinion this is wrong, it should be possible to not touch such nodes on 
package installation, regardless of the chosen ImportMode.

{noformat}
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during install.
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt to 
create or change the system maintained cache.
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
{noformat}

  was:
In OAK-3003 a persisted [principal 
cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] was 
introduced that creates _rep:cache_ nodes under authorizables.
Creating a package for such authorizables will result in including the cache 
node in there, which sounds wrong as that node is an implementation detail 
which doesn't make sense to install anywhere; however that can be avoided by 
proper filters.
What is problematic is the installation phase, if an authorizable gets packaged 
with FileVault (no rep:cache in the package) and the target user/group has a 
rep:cache node itself the importer will try (and fail as it's protected) to 
delete the persisted cache node unless the ImportMode is set to MERGE.
In my opinion this is wrong, it should be possible to not touch such nodes on 
package installation, regardless of the chosen ImportMode.

{noformat}
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during install.
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt to 
create or change the system maintained cache.
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
{noformat}


> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter:

[jira] [Updated] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCRVLT-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tommaso Teofili updated JCRVLT-128:
---
Description: 
In OAK-3003 a persisted [principal 
cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] was 
introduced that creates _rep:cache_ nodes under authorizables.
Creating a package for such authorizables will result in including the cache 
node in there, which sounds wrong as that node is an implementation detail 
which doesn't make sense to install anywhere; however that can be avoided by 
proper filters.
What is problematic is the installation phase, if an authorizable gets packaged 
with FileVault (no rep:cache in the package) and the target user/group has a 
rep:cache node itself the importer will try (and fail as it's protected) to 
delete the persisted cache node unless the ImportMode is set to MERGE.
In my opinion this is wrong, it should be possible to not touch such nodes on 
package installation, regardless of the chosen ImportMode.

{noformat}
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during install.
javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt to 
create or change the system maintained cache.
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:225)
at 
org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java:212)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.newRepositoryException(SessionDelegate.java:670)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.save(SessionDelegate.java:496)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl$8.performVoid(SessionImpl.java:419)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.performVoid(SessionDelegate.java:274)
at 
org.apache.jackrabbit.oak.jcr.session.SessionImpl.save(SessionImpl.java:416)
at org.apache.jackrabbit.vault.fs.io.AutoSave.save(AutoSave.java:175)
at org.apache.jackrabbit.vault.fs.io.Importer.run(Importer.java:416)
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:234)
at 
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.extract(ZipVaultPackage.java:153)
{noformat}

  was:
In OAK-3003 a persisted [principal 
cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] was 
introduced that creates _rep:cache_ nodes under authorizables.
Creating a package for such authorizables will result in including the cache 
node in there, which sounds wrong as that node is an implementation detail 
which doesn't make sense to install anywhere; however that can be avoided by 
proper filters.
What is problematic is the installation phase, if an authorizable gets packaged 
with FileVault (no rep:cache in the package) and the target user/group has a 
rep:cache node itself the importer will try (and fail as it's protected) to 
delete the persisted cache node unless the ImportMode is set to MERGE.
In my opinion this is wrong, it should be possible to not touch such nodes on 
package installation, regardless of the chosen ImportMode.


> System maintained cache nodes should be ignored
> ---
>
> Key: JCRVLT-128
> URL: https://issues.apache.org/jira/browse/JCRVLT-128
> Project: Jackrabbit FileVault
>  Issue Type: Bug
>Affects Versions: 3.1.28
>        Reporter: Tommaso Teofili
>
> In OAK-3003 a persisted [principal 
> cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] 
> was introduced that creates _rep:cache_ nodes under authorizables.
> Creating a package for such authorizables will result in including the cache 
> node in there, which sounds wrong as that node is an implementation detail 
> which doesn't make sense to install anywhere; however that can be avoided by 
> proper filters.
> What is problematic is the installation phase, if an authorizable gets 
> packaged with FileVault (no rep:cache in the package) and the target 
> user/group has a rep:cache node itself the importer will try (and fail as 
> it's protected) to delete the persisted cache node unless the ImportMode is 
> set to MERGE.
> In my opinion this is wrong, it should be possible to not touch such nodes on 
> package installation, regardless of the chosen ImportMode.
> {noformat}
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error during 
> install.
> javax.jcr.nodetype.ConstraintViolationException: OakConstraint0034: Attempt 
> to create or change the system maintained cache.
>   at 
> org.apache.jackrabbit.oak.api.CommitFailedException.asRepositoryException(CommitFailedException.java

[jira] [Created] (JCRVLT-128) System maintained cache nodes should be ignored

[Tommaso Teofili (JIRA)]

Tommaso Teofili created JCRVLT-128:
--

 Summary: System maintained cache nodes should be ignored
 Key: JCRVLT-128
 URL: https://issues.apache.org/jira/browse/JCRVLT-128
 Project: Jackrabbit FileVault
  Issue Type: Bug
Affects Versions: 3.1.28
Reporter: Tommaso Teofili


In OAK-3003 a persisted [principal 
cache|http://jackrabbit.apache.org/oak/docs/security/principal/cache.html] was 
introduced that creates _rep:cache_ nodes under authorizables.
Creating a package for such authorizables will result in including the cache 
node in there, which sounds wrong as that node is an implementation detail 
which doesn't make sense to install anywhere; however that can be avoided by 
proper filters.
What is problematic is the installation phase, if an authorizable gets packaged 
with FileVault (no rep:cache in the package) and the target user/group has a 
rep:cache node itself the importer will try (and fail as it's protected) to 
delete the persisted cache node unless the ImportMode is set to MERGE.
In my opinion this is wrong, it should be possible to not touch such nodes on 
package installation, regardless of the chosen ImportMode.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Require JDK7 for Oak 1.4

[Tommaso Teofili]

+1

Tommaso

Il giorno lun 19 set 2016 alle ore 10:19 Amit Jain  ha
scritto:

> +1
>
> Thanks
> Amit
>
> On Mon, Sep 19, 2016 at 12:42 PM, Chetan Mehrotra <
> chetan.mehro...@gmail.com
> > wrote:
>
> > +1
> > Chetan Mehrotra
> >
> >
> > On Mon, Sep 19, 2016 at 12:41 PM, Marcel Reutegger 
> > wrote:
> > > +1
> > >
> > > Regards
> > >  Marcel
> > >
> > >
> > > On 16/09/16 17:16, Julian Reschke wrote:
> > >>
> > >> On 2016-09-16 17:11, Davide Giannella wrote:
> > >>>
> > >>> ...
> > >>
> > >>
> > >> OK then.
> > >>
> > >>   [ ] +1 Yes, require JDK7 for Oak 1.4
> > >>   [ ] -1 No, continue to support JDK6
> > >>
> > >> This majority vote is open for at least 72 hours.
> > >>
> > >> Best regards, Julian
> > >>
> > >>
> > >
> >
>

Faster reference binary handling

[Tommaso Teofili]

Hi all,

while working with Oak S3 DS I have witnessed slowness (no numbers, just
'slow' from a user perspective) in persisting a binary using its reference;
although this may be related to some environment specific issue I wondered
about the reference binary handling we introduced in JCR-3534 [1].
In fact the implementation there requires to do something like

ReferenceBinary ref = new SimpleReferenceBinary(referenceString);
Binary referencedBinary =
session.getValueFactory().createValue(ref).getBinary();
node.setProperty("foo", referencedBinary);

on the "installation" side.
Despite all possible issues in the implementation it seems this API
requires Oak to always retrieve the binary value from the DS and then store
its value into the node whereas it'd be much better to avoid having to read
the value but instead bind it to that referenced binary.

ReferenceBinary ref = new SimpleReferenceBinary(referenceString);
if (ref.isValid()) { // referenced binary exists in the DS
  node.setProperty("foo", ref, Type.BINARY); // set a string with binary
type !?
}

I am not sure if the above code could make sense, probably not, but at
least wanted to point out the problem as to seek for possible enhancements.

Regards,
Tommaso

[1] : https://issues.apache.org/jira/browse/JCR-3534

Re: OAK SOLR re-index via index manager UI

[Tommaso Teofili]

Hi Sri,

Index Manager is not part of Apache Jackrabbit Oak, so this is not the
proper channel to get answers on that topic.

Regards,
Tommaso

Il giorno mer 20 lug 2016 alle ore 11:54 sri vaths
 ha scritto:

> Hi,We are not able to see the solr index for an re-index trigger via AEM
> 6.1 tools UI OAK index manager
>
> /libs/granite/operations/content/diagnosis/tool.html/_granite_oakindexmanager
>
> will the above UI only pick the direct index configuration under the
> /oak:index root node.
> We have placed the /oak:index node under specific content trees so that we
> need to index the entire that specific tree
> /content/sample/oak:index/solrIndex
>
> But this is not getting listed in the re-index UI
> Any idea how to bring specific paths to re-index UI
> with regardsSri

Re: [VOTE] Release Apache Jackrabbit Oak 1.2.17

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 12 lug 2016 alle ore 07:00 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 2016-07-11 07:16, Amit Jain wrote:
> > ...
>
> [X] +1 Release this package as Apache Jackrabbit Oak 1.2.17
>
> Best regards, Julian
>

Re: [VOTE] Release Apache Jackrabbit Oak 1.0.32

[Tommaso Teofili]

+1

Tommaso

Il giorno mar 12 lug 2016 alle ore 08:46 Alex Parvulescu <
alex.parvule...@gmail.com> ha scritto:

>  [X] +1 Release this package as Apache Jackrabbit Oak 1.0.32
>
> alex
>
> On Mon, Jul 11, 2016 at 4:19 PM, Dominique Jaeggi  wrote:
>
> > A candidate for the Jackrabbit Oak 1.0.32 release is available at:
> >
> > https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.0.32/
> >
> > The release candidate is a zip archive of the sources in:
> >
> >
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.0.32/
> >
> > The SHA1 checksum of the archive is
> > 3a1b5d2dcc56157c4597f12dfa6e0111d5155335.
> >
> > 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.0.32
> > 3a1b5d2dcc56157c4597f12dfa6e0111d5155335
> >
> > Please vote on releasing this package as Apache Jackrabbit Oak 1.0.32.
> > 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.0.32
> >
> > [ ] -1 Do not release this package because...
> >
> > My vote is +1.
> >
> > Thanks
> > dom.
> >
>

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.4

[Tommaso Teofili]

+1

Tommaso

Il giorno lun 11 lug 2016 alle ore 19:09 Alex Parvulescu <
alex.parvule...@gmail.com> ha scritto:

> [X] +1 Approve the release
>
> alex
>
> On Mon, Jul 11, 2016 at 5:10 PM, Francesco Mari 
> wrote:
>
> > Hi,
> >
> > We solved 3 issues in this release:
> > https://issues.apache.org/jira/browse/OAK/fixforversion/12336855
> >
> > There are still some outstanding issues:
> > https://issues.apache.org/jira/browse/OAK/component/12329487
> >
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachejackrabbit-1156
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> >
> >
> http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 1156 /tmp/oak-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
>

Re: svn commit: r1750809 - /jackrabbit/oak/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java

[Tommaso Teofili]

sure.

Regards,
Tommaso

Il giorno gio 30 giu 2016 alle ore 17:45 Chetan Mehrotra <
chetan.mehro...@gmail.com> ha scritto:

> Hi Tommaso,
>
> On Thu, Jun 30, 2016 at 8:20 PM,   wrote:
> > Modified:
> >
>  
> jackrabbit/oak/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/LucenePropertyIndex.java
>
> Can we have some backing testcase for this? It would ensure future
> refactoring does not break this requirement
>
> Chetan Mehrotra
>

Re: svn commit: r1748675 - in /jackrabbit/oak/branches/1.2: ./ oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/ oak-lucene/src/test/java/org/apache/jackrabbit/oak/plugins/index

[Tommaso Teofili]

thanks, since OAK-4499 is closed I'll create a new one.

Regards,
Tommaso

Il giorno mer 29 giu 2016 alle ore 08:14 Julian Reschke <
julian.resc...@gmx.de> ha scritto:

> On 2016-06-23 14:35, Tommaso Teofili wrote:
> > fixed in OAK-4499, I'll have a look if Jenkins keeps complaining.
> >
> > Regards,
> > Tommaso
>
> <
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/1000/jdk=jdk1.8.0_11,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.oak.plugins.index.lucene/LucenePropertyIndexTest/longRepExcerpt/
> >
>
>

Re: [VOTE] Release Apache Jackrabbit Oak Segment Tar version 0.0.2

[Tommaso Teofili]

+1

Tommaso

Il giorno mer 22 giu 2016 alle ore 15:40 Alex Parvulescu <
alex.parvule...@gmail.com> ha scritto:

>  [X] +1 Approve the release
>
> ran the script and it did not complain.
> it doesn't look like it's running any sort of build and I think there's
> value in doing that, but I don't consider this a blocker for the release.
>
>
>
>
>
> On Wed, Jun 22, 2016 at 3:23 PM, Francesco Mari 
> wrote:
>
> > Hi,
> >
> > We solved 56 issues in this release:
> > https://issues.apache.org/jira/browse/OAK/fixforversion/12336746
> >
> > There are still some outstanding issues:
> > https://issues.apache.org/jira/browse/OAK/component/12329487
> >
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachejackrabbit-1149
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> >
> >
> http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/check_staged_release.sh
> >
> > Usage:
> > sh check_staged_release.sh 1149 /tmp/oak-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
>

Re: CI builds on Windows

[Tommaso Teofili]

I'm for option 2 too!

Regards,
Tommaso


Il giorno gio 9 giu 2016 alle ore 18:03 Davide Giannella 
ha scritto:

> On 08/06/2016 08:33, Michael Dürig wrote:
> > 2. Try to enable it again and involve with the Apache infra team to
> > see what options we have to speed things up
> I'm for option 2. As Windows boxes are so slow, we may want to start
> enabling only the unit testing and see how it goes. If we see we have
> room, enable ITs. I would definitely not run pedatic on an already busy
> box.
>
> Cheers
> Davide
>
>
>

Re: API proposal for - Expose URL for Blob source (OAK-1963)

[Tommaso Teofili]

+1 to Francesco's concerns, exposing the location of a binary at the
application level doesn't sound good from a security perspective.
To me sounds like breaching the JCR and NodeState layers to directly
manipulate NodeStore binaries (from the DataStore), e.g. to perform smart
replication across different instances, but imho the right way to address
that is extending one of the current DataStore implementations or create a
new one.
I am also concerned that this Adaptable pattern would open room for other
such hacks into the stack.

My 2 cents,
Tommaso


Il giorno gio 5 mag 2016 alle ore 11:00 Francesco Mari <
mari.france...@gmail.com> ha scritto:

> This proposal introduces a huge leak of abstractions and has deep security
> implications.
>
> I guess that the reason for this proposal is that some users of Oak would
> like to perform some operations on binaries in a more performant way by
> leveraging the way those binaries are stored. If this is the case, I
> suggest those users to evaluate an applicative solution implemented on top
> of the JCR API.
>
> If a user needs to store some important binary data (files, images, etc.)
> in an S3 bucket or on the file system for performance reasons, this
> shouldn't affect how Oak handles blobs internally. If some assets are of
> special interest for the user, then the user should bypass Oak and take
> care of the storage of those assets directly. Oak can be used to store
> *references* to those assets, that can be used in user code to manipulate
> the assets in his own business logic.
>
> If the scenario I outlined is not what inspired this proposal, I would like
> to know more about the reasons why this proposal was brought up. Which
> problems are we going to solve with this API? Is there a more concrete use
> case that we can use as a driving example?
>
> 2016-05-05 10:06 GMT+02:00 Davide Giannella :
>
> > On 04/05/2016 17:37, Ian Boston wrote:
> > > Hi,
> > > If the File or URL is writable, will writing to the location cause
> issues
> > > for Oak ?
> > > IIRC some Oak DS implementations use a digest of the content to
> determine
> > > the location in the DS, so changing the content via Oak will change the
> > > location, but changing the content via the File or URL wont. If I
> didn't
> > > remember correctly, then ignore the concern.  Fully supportive of the
> > > approach, as a consumer of Oak. The locations will certainly probably
> > leak
> > > outside the context of an Oak session so the API contract should make
> it
> > > clear that the code using a direct location needs to behave
> responsibly.
> > >
> >
> > It's a reasonable concern and I'm not in the details of the
> > implementation. It's worth to keep in mind though and remember if we
> > want to adapt to URL or File that maybe we'll have to come up with some
> > sort of read-only version of such.
> >
> > For the File class, IIRC, we could force/use the setReadOnly(),
> > setWritable() methods. I remember those to be quite expensive in time
> > though.
> >
> > Davide
> >
> >
> >
>

Re: [VOTE] Please vote for the final name of oak-segment-next

[Tommaso Teofili]

oak-segment-store +1

Regards,
Tommaso

Il giorno lun 25 apr 2016 alle ore 16:52 Vikas Saurabh <
vikas.saur...@gmail.com> ha scritto:

> > oak-embedded-store +1
>
>
> Thanks,
> Vikas
>

Re: OAK +Remote SOLR OOTB integration queries

[Tommaso Teofili]

Hi Sri,

what are you trying to achieve?
Here’s some notes inline:

> On 23 Mar 2016, at 09:50, sri vaths  wrote:
> 
> Hi All,
> As in here http://jackrabbit.apache.org/oak/docs/query/solr.html
> Trying use remote SOLR with OAKa
> Need to know if these are supported
> 1) How to control Indexing child nodes of jcr:content , ex:- controlling the 
> depth via some configuration 
> 2) options to merge the child nodes into 1 single document in solr

With current version of Oak you can enable collapsing of nodes under 
jcr:content at query time (whereas your question is related to doing the same 
at indexing time, if I got it right) by enabling the “collapse jcr:content 
nodes” option [1] (and reindexing).

> 3) how to apply SOLR index inclusion & exclusion rules

can you elaborate here? Which inclusion / exclusion rules are you talking about 
specifically ?

> Please share if any such configuration exists or ideas
> with regardsSri

Looking forward to your reply.
Regards,
Tommaso

[1] : 
http://jackrabbit.apache.org/oak/docs/query/solr.html#Collapse_jcr:content_nodes

Re: [VOTE] Release Apache Jackrabbit Oak 1.4.0 (take 2)

[Tommaso Teofili]

+1

Tommaso

Il giorno gio 3 mar 2016 alle ore 09:47 Marcel Reutegger 
ha scritto:

> Hi,
>
> On 02/03/16 17:34, "Davide Giannella" wrote:
> >Please vote on releasing this package as Apache Jackrabbit Oak 1.4.0.
> >The vote is open for the next 72 hours and passes if a majority of at
> >least three +1 Jackrabbit PMC votes are cast.
>
> All checks OK.
>
> +1 Release this package as Apache Jackrabbit Oak 1.4.0
>
> Regards
>  Marcel
>
>

Re: Oak 1.3.17/1.4.0 release plan

[Tommaso Teofili]

I've fixed OAK-4068 related error (in IndexDefinitionTest).

Regards,
Tommaso

Il giorno lun 29 feb 2016 alle ore 11:22 Tommaso Teofili <
tommaso.teof...@gmail.com> ha scritto:

> and
>
> OAK-4039
>
> Il giorno lun 29 feb 2016 alle ore 11:10 Marcel Reutegger <
> mreut...@adobe.com> ha scritto:
>
>> trunk is currently broken. see:
>>
>> https://issues.apache.org/jira/browse/OAK-4068
>>
>>
>> regards
>>  marcel
>>
>> On 29/02/16 10:41, "Davide Giannella" wrote:
>>
>> >Team, a quick update on the release plan.
>> >
>> >At 11am GMT it will be the 72hrs of the jackrabbit 2.12.1 release
>> >pending votes. I will release, assuming we have votes, and include it in
>> >the oak trunk *before* branching.
>> >
>> >This means that I will branch 1.4 more or less around 2pm GMT.
>> >
>> >Any concern reply here or ping me over chat.
>> >
>> >Cheers
>> >Davide
>>
>>