Re: Using oak run to compact older versions

[Konrad Windszus]

I did the same in the past without issues.
Using the newest oak-run usually is beneficial as it got rid of some bugs….

Konrad

> On 17. Jun 2024, at 12:45, Roy Teeuwen  wrote:
> 
> Hey,
> 
> I am using an oak-core 1.22 based application (AEM 6.5) but I’d like to use 
> the features of the current oak-run jar to do parallel offline compaction. Is 
> this feasible? I tried it on a local instance and everything seems to start 
> after compaction and seems to work, but I’d like to see if there is a way to 
> be more certain that there weren’t any hidden bugs introduced.
> 
> Seeing as the segment store hasn’t needed any upgrade in the last iterations 
> of AEM, I expect we should be fine?
> 
> Groeten,
> Roy

Re: Authorizable for EveryonePrincipal

[Konrad Windszus]

I meanwhile found 
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/user/UserInitializer.java
 which creates both the admin and the anonymous user, but haven’t found out yet 
how “everyone” is being created.

> On 13. Jun 2024, at 19:30, Konrad Windszus  wrote:
> 
> Hi Angela,
> Thanks a lot for your input.
> As it turned out in some instances the according “everyone" authorizable has 
> been removed by mistake and some code cannot deal with that (due to missing 
> null checks).
> I am wondering though who Jackrabbit creates the “everyone” authorizable in 
> the first place, and why it isn’t being restored after a restart 
> automatically.
> 
> In Sling usually such setup is done via repoinit, but I guess in Oak there 
> should also be some kind of repo initialization which automatically restores 
> the most essential parts for running Oak in case of a restart,
> Maybe we can improve Oak to automatically fix such user mistakes.
> 
> Do you have some pointers to the code which creates the “everyone” 
> authorizable in the first place?
> Thanks,
> Konrad
> 
> 
>> On 13. Jun 2024, at 18:53, Angela Schreiber  
>> wrote:
>> 
>> Hi Konrad
>> 
>> There has been no change in that area for ages.
>> 
>> Oak out of the box does not mandate a Group 'everyone' to exist in the user 
>> management. It will however always exist if you retrieve it through 
>> Principal Manager in the default implementation. So,
>> 
>> 
>> *
>> every user/group accessible through user management API will have a 
>> principal attached that is also accessible through principal management API
>> *
>> no every principal accessible through the principal management API is 
>> guaranteed to be backed by a user/group in user management.
>> 
>> Reason: principals are required for access control setup. They may come from 
>> any source plugged into Oak and one source of principals is user/groups 
>> stored in the repository.
>> 
>> AEM out of the box will have a group 'everyone' installed but if you 
>> chose to remove it, the access control evaluation and principal resolution 
>> for your logged in user would still work.
>> So, testing for the lookup of the group to null, would just be defensive 
>> programming.
>> 
>> Hope that helps
>> Angela
>> 
>> 
>> 
>> From: Konrad Windszus 
>> Sent: Thursday, June 13, 2024 17:07
>> To: oak-dev@jackrabbit.apache.org 
>> Subject: Authorizable for EveryonePrincipal
>> 
>> EXTERNAL: Use caution when clicking on links or opening attachments.
>> 
>> 
>> Hi,
>> Was it always the case that the “everyone" principal could not be resolved 
>> to an Authorizable via 
>> org.apache.jackrabbit.api.security.user.UserManager.getAuthorizable()?
>> I found several places in AEM code where the return value of 
>> UserManager.getAuthorizable(Principal) is unconditionally dereferenced.
>> 
>> Is the null return value a new behaviour or has it always been like that?
>> 
>> Thanks,
>> Konrad
> 

Re: Authorizable for EveryonePrincipal

[Konrad Windszus]

Hi Angela,
Thanks a lot for your input.
As it turned out in some instances the according “everyone" authorizable has 
been removed by mistake and some code cannot deal with that (due to missing 
null checks).
I am wondering though who Jackrabbit creates the “everyone” authorizable in the 
first place, and why it isn’t being restored after a restart automatically.

In Sling usually such setup is done via repoinit, but I guess in Oak there 
should also be some kind of repo initialization which automatically restores 
the most essential parts for running Oak in case of a restart,
Maybe we can improve Oak to automatically fix such user mistakes.

Do you have some pointers to the code which creates the “everyone” authorizable 
in the first place?
Thanks,
Konrad


> On 13. Jun 2024, at 18:53, Angela Schreiber  wrote:
> 
> Hi Konrad
> 
> There has been no change in that area for ages.
> 
> Oak out of the box does not mandate a Group 'everyone' to exist in the user 
> management. It will however always exist if you retrieve it through Principal 
> Manager in the default implementation. So,
> 
> 
>  *
> every user/group accessible through user management API will have a principal 
> attached that is also accessible through principal management API
>  *
> no every principal accessible through the principal management API is 
> guaranteed to be backed by a user/group in user management.
> 
> Reason: principals are required for access control setup. They may come from 
> any source plugged into Oak and one source of principals is user/groups 
> stored in the repository.
> 
> AEM out of the box will have a group 'everyone' installed but if you 
> chose to remove it, the access control evaluation and principal resolution 
> for your logged in user would still work.
> So, testing for the lookup of the group to null, would just be defensive 
> programming.
> 
> Hope that helps
> Angela
> 
> 
> 
> From: Konrad Windszus 
> Sent: Thursday, June 13, 2024 17:07
> To: oak-dev@jackrabbit.apache.org 
> Subject: Authorizable for EveryonePrincipal
> 
> EXTERNAL: Use caution when clicking on links or opening attachments.
> 
> 
> Hi,
> Was it always the case that the “everyone" principal could not be resolved to 
> an Authorizable via 
> org.apache.jackrabbit.api.security.user.UserManager.getAuthorizable()?
> I found several places in AEM code where the return value of 
> UserManager.getAuthorizable(Principal) is unconditionally dereferenced.
> 
> Is the null return value a new behaviour or has it always been like that?
> 
> Thanks,
> Konrad

Authorizable for EveryonePrincipal

[Konrad Windszus]

Hi,
Was it always the case that the “everyone" principal could not be resolved to 
an Authorizable via 
org.apache.jackrabbit.api.security.user.UserManager.getAuthorizable()?
I found several places in AEM code where the return value of 
UserManager.getAuthorizable(Principal) is unconditionally dereferenced.

Is the null return value a new behaviour or has it always been like that?

Thanks,
Konrad

Re: Javadoc API outdated again

[Konrad Windszus]

Thanks a lot for looking into this and updating it. I added some more hints in 
https://issues.apache.org/jira/browse/OAK-10500 how to easily exclude certain 
modules from the Javadoc Aggregate creation.

Konrad

> On 18. Oct 2023, at 10:18, Julian Reschke  wrote:
> 
> On 15.10.2023 15:33, Julian Reschke wrote:
>> On 13.10.2023 11:33, Julian Reschke wrote:
>>> ...
>>> I did some checks yesterday, and we have multiple problems here (I'll
>>> try to summarize in a ticket).
>>> 
>>> On top of the shaded Guava issue (which we may be able to fix by
>>> separating it from the main project), there are also issues caused by
>>> the fact that we're trying to create aggregate docs for a large set of
>>> projects which not always use the same version of dependencies (think
>>> embedding Lucene), and there's no simple fix for that.
>>> ...
>> 
>> In the meantime, I managed to run the javadoc production for 1.46.0 and
>> 1.48.0, so we are now two versions further.
>> 
>> 1.50.0 fails for me; this is likely because it's on Java 11, whereas
>> 1.48.0 was still Java 8. Creating the Javadocs for 1.48.0 with Java 11
>> fails as well.
>> 
>> Best regards, Julian
> 
> OK, I've been able to (mostly) update the docs to 1.58.0. The process
> requires manual intervention and skips a few projects that pull in
> incompatible versions of Lucene.
> 
> See https://issues.apache.org/jira/browse/OAK-10500 for details.
> 
> Best regards, Julian

Re: Javadoc API outdated again

[Konrad Windszus]

Another option is to completely remove our hosted project-wide javadoc and just 
crosslink to an external service like 
https://javadoc.io/doc/org.apache.jackrabbit.
But from my perspective we should strive for hosting the javadoc ourselves…
Konrad

> On 12. Oct 2023, at 11:46, Julian Reschke  wrote:
> 
> On 12.10.2023 11:22, Julian Reschke wrote:
>> On 12.10.2023 09:59, Konrad Windszus wrote:
>>> Hi,
>>> The published javadoc at
>>> https://jackrabbit.apache.org/oak/docs/apidocs/overview-summary.html
>>> is again outdated. It is from Oak 1.44 while the latest release is
>>> 1.56.0.
>>> Not sure if we need to rephrase point 9. from
>>> https://jackrabbit.apache.org/jcr/creating-releases.html#part-ii-after-the-release-vote:
>>> 
>>> "consider updating the live site” feels too fuzzy. For me this is a
>>> mandatory step for stable releases.
>>> WDYT?
>>> Konrad
>> 
>> Updating the site is not trivial as it requires a plugin that does not
>> exist for Windows...
>> 
>> Best regard, Julian
> 
> What's worse is that the introduction of shaded-guava seems to have
> broken the project-wide Javadoc generation. Will need to investigate.
> 
> Best regards, Julian

Javadoc API outdated again

[Konrad Windszus]

Hi,
The published javadoc at 
https://jackrabbit.apache.org/oak/docs/apidocs/overview-summary.html is again 
outdated. It is from Oak 1.44 while the latest release is 1.56.0.
Not sure if we need to rephrase point 9. from 
https://jackrabbit.apache.org/jcr/creating-releases.html#part-ii-after-the-release-vote:

"consider updating the live site” feels too fuzzy. For me this is a mandatory 
step for stable releases.
WDYT?
Konrad

Re: [VOTE] Release Apache Jackrabbit Oak 1.54.0

[Konrad Windszus]

+1

where

[INFO] 
[INFO] Apache Maven 3.9.3 (21122926829f1ead511c958d89bd2f672198ae9f)
[INFO] OS name: "mac os x", version: "13.4.1", arch: "aarch64", family: "mac"
[INFO] Java version: 11.0.19, vendor: Eclipse Adoptium, runtime: 
/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
[INFO] MAVEN_OPTS:
[INFO] 

Konrad

> On 19. Jul 2023, at 18:56, Julian Reschke  wrote:
> 
> A candidate for the Jackrabbit Oak 1.54.0 release is available at:
> 
>https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.54.0/
> 
> The release candidate is a zip archive of the sources in:
> 
> https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.54.0/
> 
> The SHA1 checksum of the archive is
> 95f1b68153a1b3d3adf9e9d8aaac9c90325edbcb.
> 
> 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.54.0
> 95f1b68153a1b3d3adf9e9d8aaac9c90325edbcb
> 
> Please vote on releasing this package as Apache Jackrabbit Oak 1.54.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.54.0
>[ ] -1 Do not release this package because...
> 
> Best regards, Julian

[ANNOUNCE] Apache Jackrabbit FileVault 3.7.0 released

[Konrad Windszus]

The Apache Jackrabbit community is pleased to announce the release of
Apache Jackrabbit FileVault 3.7.0. The release is available for download at:

http://jackrabbit.apache.org/downloads.html

See the full release notes below for details about this release:

Release Notes - Jackrabbit FileVault - Version 3.7.0
This version requires Java 8
The OSGi bundles depend on Jackrabbit 2.20.8+ (JCR Commons, SPI, SPI Commons), 
Oak JR API 1.22.4+, Commons IO 2.7+, Commons Collections 4.1+ and SLF4J 1.7+

Bug
* [JCRVLT-677] - NPE during "vlt checkout" with --force on existing repository
* [JCRVLT-683] - Import of Authorizable node with acHandling=IGNORE should 
preserve existing rep:principalPolicy child node
* [JCRVLT-684] - Mixins recovered using stashing set on incorrect node
* [JCRVLT-685] - ImportMode REPLACE vs IdConflictPolicy LEGACY vs stashing
* [JCRVLT-689] - bad description of "isStrict" flag
* [JCRVLT-693] - Escape values for type javax.jcr.PropertyType.UNDEFINED
* [JCRVLT-699] - Installation of Sub Packages fails if Maven Reproducible 
Builds are enabled
* [JCRVLT-700] - package creation fails for node names that are valid in Oak, 
but invalid in Jackrabbit
* [JCRVLT-701] - add test coverage for non-ASCII whitespace inside node names 
on packaging
* [JCRVLT-703] - Nodetype Validator reports wrong path for missing binary node
* [JCRVLT-705] - Unprotected properties with name jcr:created and jcr:createdBy 
are no longer contained in the export
* [JCRVLT-708] - Raise minimum runtime requirement to Jackrabbit 2.20.4 and 
Jackrabbit API 1.22.14

Improvement
* [JCRVLT-671] - Add Validator SPI targeted towards OSGi configurations
* [JCRVLT-688] - Add "generator" information to packages generated by filevault
* [JCRVLT-690] - Allow to prevent session.save() and session.reset(false) 
inside Importer.run()
* [JCRVLT-692] - Run ITs with minimum and maximum Oak version
* [JCRVLT-696] - add logging for primary node type changes
* [JCRVLT-697] - Moving child nodes around should be calculated towards the 
autosave threshold
* [JCRVLT-704] - Expose line and column in NodeContext
* [JCRVLT-706] - jackrabbit-packagetype validator: Use legacy type severity for 
mixed packages inside container packages
* [JCRVLT-710] - Update to ASF Parent 30

Task
* [JCRVLT-678] - avoid use of transitively inherited commons-collections in 
FSPackageRegistryIT
* [JCRVLT-679] - update to Jackrabbit 2.20.8 and Oak 1.48.0
* [JCRVLT-680] - vault validation tests fail when Jackrabbit dependency is 
current
* [JCRVLT-695] - Improve logging wrt node stashing
* [JCRVLT-707] - Update maximum versions to Jackrabbit 2.20.10 and Oak 1.52.0


Release Contents


This release consists of a single source archive packaged as a zip file.
The archive can be unpacked with the jar tool from your JDK installation.
See the README.md file for instructions on how to build this release.

The source archive is accompanied by a SHA512 checksums and a PGP
signature that you can use to verify the authenticity of your
download. The public key used for the PGP signature can be found at
https://www.apache.org/dist/jackrabbit/KEYS.

About Apache Jackrabbit FileVault
---

The FileVault introduces a JCR repository to filesystem mapping. The mapping
is exposed by an API and used by the "FileVault Content Packages" which allow to
create portable packages of repository content.

The Vault Command Line Interface aka "vlt" provides a subversion like
utility to work and develop with repository content.

For more information, visit https://jackrabbit.apache.org/filevault

About The Apache Software Foundation


Established in 1999, The Apache Software Foundation provides organizational,
legal, and financial support for more than 140 freely-available,
collaboratively-developed Open Source projects. The pragmatic Apache License
enables individual and commercial users to easily deploy Apache software;
the Foundation's intellectual property framework limits the legal exposure
of its 3,800+ contributors.

For more information, visit http://www.apache.org/

Re: Require OSGi R7

[Konrad Windszus]

If there are no further comments, I am gonna merge 
https://github.com/apache/jackrabbit-oak/pull/1015 end of next week.
Konrad

> On 10. Jul 2023, at 10:14, Konrad Windszus  wrote:
> 
> Hi Marcel,
> 
> 
>> On 10. Jul 2023, at 09:06, Marcel Reutegger  
>> wrote:
>> 
>> Hi Konrad
>> 
>> On 03.07.23, 13:27, "Konrad Windszus"  wrote:
>>> I would recommend to require at least OSGi R7 for Oak (released in 2018)
>>> and at the same time no longer use the aggregate dependency but rather
>>> the individual chapter dependencies of OSGi separately [3] which are
>>> (from Compendium)
>>> - Configuration Admin 1.6
>>> - Declarative Services 1.4
>>> - Metatype Service 1.4
>>> 
>>> Does anything speak against raising the dependencies accordingly?
>> 
>> Does this require any code changes? I vaguely remember an earlier attempt
>> to update OSGi configuration related code throughout the project, which
>> required many changes and could introduced subtle changes in behaviour if
>> not done correctly.
> 
> No it doesn’t require code changes (except for maybe adding some explicit 
> cast to resolve ambiguous method calls. See the PR at 
> https://github.com/apache/jackrabbit-oak/pull/1015.
> You are probably referring to https://issues.apache.org/jira/browse/OAK-6741 
> which is different from this approach, as this is only about updating to a 
> newer version (of the same APIs/Specs) not migrating.
>> 
>>> Is there any known consumer still relying on Oak in an OSGi container
>>> which is not at least R7 compliant?
>> 
>> Can you provide more details how this manifests? Thanks.
> Sure.
> As usual newer dependencies lead to import-package headers with version 
> ranges starting with the newer version as lower bound 
> (https://bnd.bndtools.org/chapters/170-versioning.html#import-version-policy)
> In addition for OSGi Declarative Services there are capabilities being added 
> to the Manifest which require DS 1.4 or newer 
> (https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-capabilities)
> Both lead to the fact that bundles do not start any longer in OSGi containers 
> not providing the necessary OSGi specifications in at least the given version.
> 
> Hope this clarifies things,
> Konrad
>> 
>> Regards
>> Marcel

Re: Require OSGi R7

[Konrad Windszus]

Hi Marcel,


> On 10. Jul 2023, at 09:06, Marcel Reutegger  
> wrote:
> 
> Hi Konrad
> 
> On 03.07.23, 13:27, "Konrad Windszus"  wrote:
>> I would recommend to require at least OSGi R7 for Oak (released in 2018)
>> and at the same time no longer use the aggregate dependency but rather
>> the individual chapter dependencies of OSGi separately [3] which are
>> (from Compendium)
>> - Configuration Admin 1.6
>> - Declarative Services 1.4
>> - Metatype Service 1.4
>> 
>> Does anything speak against raising the dependencies accordingly?
> 
> Does this require any code changes? I vaguely remember an earlier attempt
> to update OSGi configuration related code throughout the project, which
> required many changes and could introduced subtle changes in behaviour if
> not done correctly.

No it doesn’t require code changes (except for maybe adding some explicit cast 
to resolve ambiguous method calls. See the PR at 
https://github.com/apache/jackrabbit-oak/pull/1015.
You are probably referring to https://issues.apache.org/jira/browse/OAK-6741 
which is different from this approach, as this is only about updating to a 
newer version (of the same APIs/Specs) not migrating.
> 
>> Is there any known consumer still relying on Oak in an OSGi container
>> which is not at least R7 compliant?
> 
> Can you provide more details how this manifests? Thanks.
Sure.
As usual newer dependencies lead to import-package headers with version ranges 
starting with the newer version as lower bound 
(https://bnd.bndtools.org/chapters/170-versioning.html#import-version-policy)
In addition for OSGi Declarative Services there are capabilities being added to 
the Manifest which require DS 1.4 or newer 
(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#service.component-capabilities)
Both lead to the fact that bundles do not start any longer in OSGi containers 
not providing the necessary OSGi specifications in at least the given version.

Hope this clarifies things,
Konrad
> 
> Regards
> Marcel

Require OSGi R7

[Konrad Windszus]

Hi,
Currently Oak is compiled against the pretty much outdated OSGi Core and 
Compendium Spec 4.2 [1].
However the component annotations are used in version 1.3 (introduced with OSGi 
Compendium 6) [2]. The component annotations have not only an impact on the 
build time but also on the run time, therefore for edge cases some code may 
already be incompatible with OSGi Declarative Service 1.1 (shipped with OSGi 
Compendium Spec 4.2). I particularly would like to rely on constructor 
injection 
(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html#d0e46608)
 which eases dealing with components to be used inside and outside OSGi 
runtimes.

I would recommend to require at least OSGi R7 for Oak (released in 2018) and at 
the same time no longer use the aggregate dependency but rather the individual 
chapter dependencies of OSGi separately [3] which are (from Compendium)
- Configuration Admin 1.6 
(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.cm.html)
- Declarative Services 1.4 
(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.component.html)
- Metatype Service 1.4 
(https://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.metatype.html)

Does anything speak against raising the dependencies accordingly?
Is there any known consumer still relying on Oak in an OSGi container which is 
not at least R7 compliant?

Thanks,
Konrad


[1] - 
https://github.com/apache/jackrabbit-oak/blob/25c01b81768c77e558078a92a31309910902f3a0/oak-parent/pom.xml#L495
[2] - 
https://github.com/apache/jackrabbit-oak/blob/25c01b81768c77e558078a92a31309910902f3a0/oak-parent/pom.xml#L500
[3] - https://issues.apache.org/jira/browse/OAK-9837

Re: Referential Integrity of Access Control Policies

[Konrad Windszus]

Thanks, will try to come up with a documentation PR.
Konrad

> On 28. Apr 2023, at 12:07, Angela Schreiber  wrote:
> 
> Hi Konrad
> 
> There exists no automatic cleanup for access control entries bound to a 
> specific principal or path.
> 
> If the tree where the policy is stored gets deleted (or any of it's parents 
> for that matter) the policy node will be removed. This may or may not be the 
> access-controlled tree where the policy (or it's entries) take effect (see 
> JCR specification about the effect of access control policies). 
> Alternatively, the policy itself can be removed using 
> AccessControlManager#removePolicy.
> 
> In other words:
> 
>  *   you can have/define resource-based ACEs for non-existing principals
>  *   you can have/define principal-based ACEs for non-existing paths
> 
> Hope that helps
> Angela
> 
> 
> 
> 
> From: Konrad Windszus 
> Sent: Friday, April 28, 2023 11:53
> To: oak-dev@jackrabbit.apache.org 
> Subject: Referential Integrity of Access Control Policies
> 
> 
> Hi,
> How are access control policies supposed to behave in case the referenced 
> principal or node path is deleted? Are they automatically cleaned up?
> 
> They are automatically deleted whenever the parent node is being deleted 
> (while for resource based ACLs this is expected and makes sense for principal 
> ACLs this may sometimes lead to surprises).
> 
> I would like to add a paragraph to both 
> https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html
>  and 
> https://jackrabbit.apache.org/oak/docs/security/accesscontrol/default.html to 
> document this, so I would appreciate some pointers.
> 
> Thanks in advance,
> Konrad
> 
> 

Referential Integrity of Access Control Policies

[Konrad Windszus]

Hi,
How are access control policies supposed to behave in case the referenced 
principal or node path is deleted? Are they automatically cleaned up?

They are automatically deleted whenever the parent node is being deleted (while 
for resource based ACLs this is expected and makes sense for principal ACLs 
this may sometimes lead to surprises).

I would like to add a paragraph to both 
https://jackrabbit.apache.org/oak/docs/security/authorization/principalbased.html
 and https://jackrabbit.apache.org/oak/docs/security/accesscontrol/default.html 
to document this, so I would appreciate some pointers.

Thanks in advance,
Konrad

Re: How to check if user is anonymous

[Konrad Windszus]

>> 
>> In the context of a Sling request the API to call would be 
>> https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html#getUserPrincipal--
>>  : a null return value corresponds to the anonymous access.
>> 
> 
> This does not work for me. I get back 
> org.apache.jackrabbit.oak.security.user.TreeBasedPrincipal:anonymous
> (In AEM).

FTR: This seems to violate the servlet spec, I therefore opened 
https://issues.apache.org/jira/browse/SLING-11825.

Re: How to check if user is anonymous

[Konrad Windszus]

Hi Angela,
Thanks for the insights,


> On 12. Apr 2023, at 11:15, Angela Schreiber  wrote:
> 
> Hi Konrad
> 
> There is no public API to check that as it is an implementation detail that 
> the unauthenticated guest session is in oak backed by a user.
> 
> So, I suspect the question you want to have an answer for is whether a given 
> JCR session is an unauthenticated guest session or not. Is that correct?
Exactly!
> 
> In the context of a Sling request the API to call would be 
> https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html#getUserPrincipal--
>  : a null return value corresponds to the anonymous access.
> 

This does not work for me. I get back 
org.apache.jackrabbit.oak.security.user.TreeBasedPrincipal:anonymous
(In AEM)
But it seems that 
https://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getRemoteUser()
 works, i.e. returns null for anonymous users.

> In Jcr/Oak no corresponding method exist as it usually does not matter 
> through which authentication mechanism a given session has been obtained.
In my case retrieving the session is done under the hood (by Sling), so I need 
to use some API to do that check.

> 
> But maybe you want to share a bit of context on what you aim to achieve?
> 
> Kind regards
> Angela
> 
> 
> 
> From: Konrad Windszus 
> Sent: Wednesday, April 12, 2023 10:49
> To: oak-dev@jackrabbit.apache.org 
> Subject: How to check if user is anonymous
> 
> EXTERNAL: Use caution when clicking on links or opening attachments.
> 
> 
> How do I figure out if a org.apache.jackrabbit.api.security.user.User object 
> is representing the anonymous user[1] or not.
> Unfortunately the interface only has methods isAdmin and isSystemUser [2]
> Any pointers appreciated.
> Thanks in advance,
> Konrad
> 
> 
> [1] - 
> https://jackrabbit.apache.org/oak/docs/security/user/default.html#anonymous-user
> [2] - 
> https://javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/org/apache/jackrabbit/api/security/user/User.html

Re: How to check if user is anonymous

[Konrad Windszus]

The method at 
https://github.com/apache/jackrabbit-oak/blob/160d2be57c8e7733466a5bbe9ee88afaa2025c96/oak-security-spi/src/main/java/org/apache/jackrabbit/oak/spi/security/user/util/UserUtil.java#L56
 requires to pass the 
org.apache.jackrabbit.oak.spi.security.ConfigurationParameters object, so I am 
wondering whether there is an easier solution than just comparing the id 
against this method’s return value….
Just checking against a hardcoded user id seems wrong as well, as this can be 
potentially reconfigured.

> On 12. Apr 2023, at 10:49, Konrad Windszus  wrote:
> 
> How do I figure out if a org.apache.jackrabbit.api.security.user.User object 
> is representing the anonymous user[1] or not.
> Unfortunately the interface only has methods isAdmin and isSystemUser [2]
> Any pointers appreciated.
> Thanks in advance,
> Konrad
> 
> 
> [1] - 
> https://jackrabbit.apache.org/oak/docs/security/user/default.html#anonymous-user
> [2] - 
> https://javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/org/apache/jackrabbit/api/security/user/User.html

How to check if user is anonymous

[Konrad Windszus]

How do I figure out if a org.apache.jackrabbit.api.security.user.User object is 
representing the anonymous user[1] or not.
Unfortunately the interface only has methods isAdmin and isSystemUser [2]
Any pointers appreciated.
Thanks in advance,
Konrad


[1] - 
https://jackrabbit.apache.org/oak/docs/security/user/default.html#anonymous-user
[2] - 
https://javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/org/apache/jackrabbit/api/security/user/User.html

Re: Junit TemporaryFolder considered harmful

[Konrad Windszus]

Using JUnit5 would help in that case: 
https://junit.org/junit5/docs/5.4.0-RC1/api/org/junit/jupiter/api/support/io/TempDirectory.html.
 Maybe it is time to upgrade…

> Am 27.01.2023 um 17:09 schrieb Julian Reschke :
> 
> ...that is, when used with default settings.
> 
> Because, by default, it will not complain when files inside the
> temporary folder can not be removed - and that is usually the case when
> file handles were left open.
> 
> Yes, Unix and Linux can remove entries for open files, but that doesn't
> mean leaving files open is a good idea.
> 
> Please use
> 
>> @Rule
>>public final TemporaryFolder temporaryFolder = 
>> TemporaryFolder.builder().assureDeletion().build();
> 
> instead. At least on Windows you'll see failures in these cases, and I
> consider that a feature (in this use case).
> 
> Best regards, Julian

Re: Authorisation Restrictions: When are those evaluated?

[Konrad Windszus]

> On 10. Jan 2023, at 12:11, Angela Schreiber  wrote:
> 
> hi konrad
> 
>> you cannot limit creation of a new node with a specific node type (with a 
>> node
>> type restriction ACE) nor the migration of an existing node to a certain node
>> type to certain principals only.
> 
> for changing primary type should be doable if it applies to a dedicated 
> subtree.

How exactly?

> what i wanted to state is: if you want it to be enforced for all nodes across 
> the whole content tree it might become tricky to manage if additional entries 
> allowed writing in a subtree so, the requirement 'for a given principal 
> certain restrictions should be applied across the whole repository content' 
> cannot easily be reflected with the resource-based access control model afaik.
> 
> for adding nodes: note that jcr:addChildNodes privilege is evaluated on the 
> parent and not for the node to be added. so, the restriction would need to be 
> applied with an ACE that grants/denies adding the jcr:primaryType property 
> which is mandatory for all nodes and thus is an indication of the add-node 
> operation.

Granted, but as I might add the parent node of the restricted node type in the 
same session that does not really help here, so I can still add the node with 
the restricted node type, right?

> 
>> Therefore it is probably reasonable to document that it is not reasonable to 
>> use
>> property evaluating restrictions with write permissions
> 
> i wouldn't say that though. one just has to be aware that add/remove node is 
> granted on the parent (remove also on the node itself).
> 
> kind regards
> angela
> 
> 
> 
> From: Konrad Windszus 
> Sent: Tuesday, January 10, 2023 11:15
> To: oak-dev@jackrabbit.apache.org 
> Subject: Re: Authorisation Restrictions: When are those evaluated?
> 
> EXTERNAL: Use caution when clicking on links or opening attachments.
> 
> 
> Thanks Angela for the response and happy new year to you as well
> 
>> On 10. Jan 2023, at 10:27, Angela Schreiber  
>> wrote:
>> 
>> the current restriction API does not allow to limit to/for certain 
>> principals. restrictions are not aware of the principal a given entry is 
>> evaluated for but are only aware of the path and the item the permissions 
>> applies to.
> 
> The question was more whether the item which is evaluated by the restriction 
> in the case of write operations is the before or after state in the 
> repository.
> 
> I guess it is just the before state, which means that you cannot limit 
> creation of a new node with a specific node type (with a node type 
> restriction ACE) nor the migration of an existing node to a certain node type 
> to certain principals only.
> 
> Therefore it is probably reasonable to document that it is not reasonable to 
> use property evaluating restrictions with write permissions, am I right?
> 
> 
> Konrad

Re: Authorisation Restrictions: When are those evaluated?

[Konrad Windszus]

Thanks Angela for the response and happy new year to you as well

> On 10. Jan 2023, at 10:27, Angela Schreiber  wrote:
> 
> the current restriction API does not allow to limit to/for certain 
> principals. restrictions are not aware of the principal a given entry is 
> evaluated for but are only aware of the path and the item the permissions 
> applies to.

The question was more whether the item which is evaluated by the restriction in 
the case of write operations is the before or after state in the repository.

I guess it is just the before state, which means that you cannot limit creation 
of a new node with a specific node type (with a node type restriction ACE) nor 
the migration of an existing node to a certain node type to certain principals 
only.

Therefore it is probably reasonable to document that it is not reasonable to 
use property evaluating restrictions with write permissions, am I right?


Konrad

Authorisation Restrictions: When are those evaluated?

[Konrad Windszus]

Hi,
I haven’t found any hint in 
https://jackrabbit.apache.org/oak/docs/security/authorization/restriction.html 
on when the restrictions are being evaluated.
Is it before the changes have been committed, afterwards or both?

This is particularly crucial to know for restrictions evaluating properties 
which are modified through a commit (e.g. a node name through Session.move(…), 
a property value modification via Node.setProperty(…), a primary type change 
via Node.setPrimaryType()).

For example is it possible to restrict writing of nodes with a particular type 
(irrespective of their location and parent node structure) to only a certain 
principal?

Thanks in advance,
Konrad

Re: Oak Jenkins build takes up too many resources

[Konrad Windszus]

Maybe adding some logic to only build modified modules helps like outlined in 
https://github.com/mrguamos/jenkins-pipeline-maven-multi-module/blob/master/Jenkinsfile
 
<https://github.com/mrguamos/jenkins-pipeline-maven-multi-module/blob/master/Jenkinsfile>.
Hard though to figure out transitive dependencies with that.

Another approach is the new 
https://maven.apache.org/extensions/maven-build-cache-extension/ 
<https://maven.apache.org/extensions/maven-build-cache-extension/> (see also 
https://www.youtube.com/watch?v=DEQG4CNFMFE 
<https://www.youtube.com/watch?v=DEQG4CNFMFE>) which should also gain quite 
some improvements (I don’t have any experience though with it). 


> On 16. Dec 2022, at 19:59, Konrad Windszus  wrote:
> 
> The situation is still pretty bad. Right now Oak jobs take up roughly 300 
> jobs of total 450 in the queue. We should ASAP switch to incremental builds 
> (i.e. only trigger builds for modules which really have changed) and no 
> longer trigger 100s of build jobs in parallel for a single branch!
> 
> @Marcel: Are you still looking into optimizations?

Re: Oak Jenkins build takes up too many resources

[Konrad Windszus]

The situation is still pretty bad. Right now Oak jobs take up roughly 300 jobs 
of total 450 in the queue. We should ASAP switch to incremental builds (i.e. 
only trigger builds for modules which really have changed) and no longer 
trigger 100s of build jobs in parallel for a single branch!

@Marcel: Are you still looking into optimizations?

Re: [Release Plan] Apache Jackrabbit Oak 1.46.0

[Konrad Windszus]

-1 on that proposal. Why revert the plugin updates if there is an easy fix? 
Managing each plugin update in individual JIRA/commit is an effort I am not 
willing to invest. Also this wouldn’t have made this issue any easier to 
detect. From my perspective backporting the plugin updates as a whole to 1.22 
should be no real problem.

Konrad

> Am 16.12.2022 um 06:55 schrieb Julian Reschke :
> 
> On 16.12.2022 04:53, Nitin Gupta wrote:
>> FYI, the release is currently blocked on
>> https://issues.apache.org/jira/browse/OAK-10032.
>> 
>> Regards,
>> Nitin
> 
> My proposal is to back out the change and make that release.
> 
> Once that is done, we can and should address the individual tasks in
> that commit separately. In particular, avoiding the whole issue of
> having to use the ant maven plugin to copy a file might be best (as
> suggested by Konrad),
> 
> Separating these issues into smaller tasks will be useful when we decide
> which of these to backport to 1.22.
> 
> Best regards, Julian
> 

Re: Oak Jenkins build takes up too many resources

[Konrad Windszus]

Probably it would also be fair to not parallelise all modules (i.e. reserve 
only handful number of slots instead of almost all available).
Currently we trigger 35 builds at the same time: 
https://github.com/apache/jackrabbit-oak/blob/6c04951be723c4574d3a7c1bcc4ec04e9f9e7dd0/Jenkinsfile#L23
 
<https://github.com/apache/jackrabbit-oak/blob/6c04951be723c4574d3a7c1bcc4ec04e9f9e7dd0/Jenkinsfile#L23>
 while ASF Jenkins has only about the same amount of slots.
I think we should block at most a handful of nodes in parallel (although this 
may lead to slightly slower build times).

Konrad

> On 14. Nov 2022, at 16:29, Konrad Windszus  wrote:
> 
> Seems this is pretty easy: https://stackoverflow.com/a/70375236 
> <https://stackoverflow.com/a/70375236>
> Can you come up with a PR?
> Thanks,
> Konrad
> 
>> On 14. Nov 2022, at 16:16, Marcel Reutegger  
>> wrote:
>> 
>> Hi,
>> 
>> On 11.11.22, 15:11, "Robert Munteanu"  wrote:
>>> I think it would be worthile to check if the build can be optimised,
>>> otherwise Oak builds are blocking many execution slots of the Jenkins
>>> ASF instance.
>> 
>> I did notice one thing. Our PRs may schedule a build each time commits
>> are pushed to the branch. Is there a way to cancel an already running
>> build when there are new changes coming in from a PR?
>> 
>> Regards
>> Marcel
> 

Re: Oak Jenkins build takes up too many resources

[Konrad Windszus]

Seems this is pretty easy: https://stackoverflow.com/a/70375236 

Can you come up with a PR?
Thanks,
Konrad

> On 14. Nov 2022, at 16:16, Marcel Reutegger  
> wrote:
> 
> Hi,
> 
> On 11.11.22, 15:11, "Robert Munteanu"  wrote:
>> I think it would be worthile to check if the build can be optimised,
>> otherwise Oak builds are blocking many execution slots of the Jenkins
>> ASF instance.
> 
> I did notice one thing. Our PRs may schedule a build each time commits
> are pushed to the branch. Is there a way to cancel an already running
> build when there are new changes coming in from a PR?
> 
> Regards
> Marcel

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Konrad Windszus]

> On 22. Jul 2022, at 12:21, Marcel Reutegger  
> wrote:
> 
> In my view this information is useless
> and I'd even suggest we remove it.


I use this information to quickly check:

- which is the latest release
- whether the documentation is probably outdated

But I don’t a very strong opinion on keeping it. 
What do others think?

Konrad

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Konrad Windszus]

> 
> I did not make any changes to Oak pages. So I didn't see a need to update
> that part of the website.
The version Is part of the header contained in every page of the site, so IMHO 
a release (i.e. version change) requires a republish.

> 
> The JavaDocs I forgot to generate and I'll do that right away.

Thanks.
> 
>> Do we need to make that more explicit in
>> https://jackrabbit.apache.org/jcr/creating-releases.html#part-ii-after-
>> the-release-vote?
> 
> Yes, might be good to amend point 9. It talks about Jackrabbit, which is
> probably the reason why I skipped it. A pointer to oak-doc/README.md
> would also be helpful.
> 
> Regards
> Marcel

Re: [ANNOUNCE] Apache Jackrabbit Oak 1.44.0 released

[Konrad Windszus]

Hi Marcel,
Neither the website (https://jackrabbit.apache.org/oak/docs/index.html 
) nor the published javadoc 
(https://jackrabbit.apache.org/oak/docs/apidocs/ 
) have been updated 
unfortunately.
Do we need to make that more explicit in 
https://jackrabbit.apache.org/jcr/creating-releases.html#part-ii-after-the-release-vote?
 


Konrad


> On 18. Jul 2022, at 08:00, Marcel Reutegger  wrote:
> 
> The Apache Jackrabbit community is pleased to announce the release of
> Apache Jackrabbit Oak 1.44.0. The release is available for download at:
> 
> http://jackrabbit.apache.org/downloads.html
> 
> See the full release notes below for details about this release:
> 
> Release Notes -- Apache Jackrabbit Oak -- Version 1.44.0
> 
> Introduction
> 
> 
> Jackrabbit Oak is a scalable, high-performance hierarchical content
> repository designed for use as the foundation of modern world-class
> web sites and other demanding content applications.
> 
> Apache Jackrabbit Oak 1.44.0 is an incremental feature release based
> on and compatible with earlier stable Jackrabbit Oak 1.x
> releases. This release is considered stable and targeted for
> production use.
> 
> While Oak 1.44.0 compiles and tests successfully on Java 17, Javadocs
> generation fails on Java 17 (but works as expected on Java 8).
> 
> The Oak effort is a part of the Apache Jackrabbit project.
> Apache Jackrabbit is a project of the Apache Software Foundation.
> 
> Changes in Oak 1.44.0
> -
> 
> Technical task
> 
>[OAK-9585] - BrokenNetworkIT fails on Java 17
>[OAK-9703] - benchmarks comparing new restrictions to rep:glob
>[OAK-9833] - UpgradeIT fails on Java 17
> 
> Bug
> 
>[OAK-9564] - Lease failure when update takes longer than socket timeout
>[OAK-9649] - Improve multithreaded download retry strategy during indexing
>[OAK-9656] - Recovery runs mistakenly when system clock jumps ahead
>[OAK-9676] - In CompositeNodeStore, mounts are ignored when
> iterating through child nodes
>[OAK-9684] - elastic: avoid ingesting FVs with size different from
> the one in the index definition
>[OAK-9695] - Deleting a property fails in case there is a residual
> protected property definition in its node type with a non-matching
> type
>[OAK-9700] - RevisionGC may fail with NPE
>[OAK-9708] - Invalid logging of 'improper' regex WARN
>[OAK-9709] - PropertyDelegate.isProtected() throws NPE when parent is stale
>[OAK-9729] - Reduce execution time for oak-search-elastic tests
>[OAK-9732] - oak-it-osgi ITs broken on Windows
>[OAK-9735] - Reset/update corrupt index counter in metrics
>[OAK-9736] - oak-store-composite ITs broken
>[OAK-9750] - Oak-search-elastic: Add right tika dependency
>[OAK-9751] - Exception while reading external changes from journal
>[OAK-9769] - PathPredicate not being used properly when building
> FlatFileStore
>[OAK-9773] - DefaultSyncContext#syncMembership() compares external
> ids case-sensitively
>[OAK-9775] - ACEs with unsupported restrictions must be cleared upon 
> editing
>[OAK-9779] - PermissionConstants.PERMISSION_PROPERTY_NAMES does
> not list rep:isAllow
>[OAK-9782] - CompositeRestrictionProvider must call validate on
> aggregated providers
>[OAK-9791] - Missing check for restriction node being present
>[OAK-9793] - AbstractRestrictionProvider: validation to respect
> aggregation for unsupported paths
>[OAK-9797] - Direct access blob cache override breaks metrics and 
> monitoring
>[OAK-9798] - Inconsistent handling of supported permissions in
> CompositePermissionProviderOr
>[OAK-9809] - oak-run server: update Jetty because of outdated
> servlet API version
>[OAK-9813] - [oak-run-commons] LoggingInitializer shutdownLogging
> should not shut down if not initialized
>[OAK-9817] - Index stats logging indexing cycle failures after
> changes from OAK-9802
> 
> Epic
> 
>[OAK-9538] - Oak should compile & test on Java 17
>[OAK-9614] - Document best pratices for Oak Access Control
> Management and Permission Evaluation
> 
> New Feature
> 
>[OAK-9680] - Container level SAS URI Support in Oak-Segment-Azure
>[OAK-9689] - When BlobEndpoint is not configured use AccountName
> in connection string for  Azure  blob store connector
>[OAK-9704] - oak-blob-cloud-azure: in AzureBlobStoreBackend,
> interpret empty string like null for boolean properties
> 
> Story
> 
>[OAK-9726] - Improve index purge old version commands logs
>[OAK-9734] - Index purge should prevent fully delete index
> definition which is is read-only repo
> 
> Improvement
> 
>[OAK-9612] - write to a readonly builder throws a
> java.lang.UnsupportedOperationException
>[OAK-9662] - Perform inequality matches in Lucene+Elastic,

Re: Jackrabbit Oak 1.44.0 release plan

[Konrad Windszus]

Hi Marcel,

Although I appreciate a release, I see that this has been done already now.
I would appreciate if you would give the Jackrabbit community a bit more in 
advance notice (maybe one week) to allow others to contribute fixes and also to 
consider at least the approved PR reviews: 
https://github.com/apache/jackrabbit-oak/pulls?q=is%3Apr+is%3Aopen+review%3Aapproved
 

 (9 in total)

The amount of open PRs (172) also seems to indicate that the process for 
contributions does not work well.
Maybe everyone of the Oak committers can dedicate some more time to do timely 
reviews…

I personally won’t be able to vote on a potential 1.44.0 release as the testing 
fails for me locally due to https://issues.apache.org/jira/browse/OAK-9679 
 (with an open PR at 
https://github.com/apache/jackrabbit-oak/pull/612 
)

Maybe for the next release we can all try to pay more attention to the open PRs.

Thanks,

Konrad


> On 11. Jul 2022, at 17:08, Marcel Reutegger  
> wrote:
> 
> Hi,
> 
> It’s been more than 6 month since the last Oak feature release. I’d like to 
> release 1.44.0 after blocking issues have been resolved.
> 
> Issues currently open for 1.44.0 are here:
> 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20OAK%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.44.0
> 
> I consider the Java 17 related issues and OAK-9669 a blocker, but not the 
> various improvements scheduled for 1.44.0.
> 
> Let me know if you have any objections.
> 
> Regards
> Marcel

Re: Flaky unit-tests on Jenkins

[Konrad Windszus]

In this case I would say no harm in doing the merge prior to fixing Jenkins. 
Those test failures are anyways flaky. But would be good to track those in JIRA 
with according logs, so it can be investigated later on.

Konrad

> On 5. Jul 2022, at 17:47, Jörg Hoh  wrote:
> 
> Hi,
> 
> I just wanted to merge https://github.com/apache/jackrabbit-oak/pull/605
> but I am bit hesitant to do so, because I saw some test failures which have
> nothing to do with the actual PR.
> 
> Failing are these modules:
> * oak-store-document
> * oak-segment-azure
> * oak-blob-plugins
> 
> should I merge anyway and we will check them later or should we first try
> to investigate into these test failures?
> 
> Jörg
> 
> -- 
> Cheers,
> Jörg Hoh,
> 
> https://cqdump.joerghoh.de
> Twitter: @joerghoh

Re: Javadocs

[Konrad Windszus]

Thanks,
I also raised https://github.com/apache/jackrabbit-oak/pull/478/files 
<https://github.com/apache/jackrabbit-oak/pull/478/files> to add links to the 
Jackrabbit API.
Please have a look,
Konrad

> On 1. Feb 2022, at 12:19, Marcel Reutegger  wrote:
> 
> Hi,
> 
> On 31.01.22, 16:50, "Konrad Windszus"  wrote:
>> Can we publish the most recent release again?
> 
> Apologies, I don't know why that happened. It looks like I was
> updating the website in November 2021 with some minor corrections
> and this also wiped Javadoc.
> 
> I re-generated the site with Javadoc and they are back online.
> 
> Regards
> Marcel
> 

Re: Javadocs

[Konrad Windszus]

> On 31. Jan 2022, at 17:27, Julian Reschke  wrote:
> 
> Am 31.01.2022 um 16:50 schrieb Konrad Windszus:
>> Hi,
>> What happened to https://jackrabbit.apache.org/oak/docs/apidocs/?
>> It now only contains some shell script and options containing absolute 
>> filesystem paths from Marcel Reutegger's local machine 
>> (https://jackrabbit.apache.org/oak/docs/apidocs/options).
>> Can we publish the most recent release again?
> 
> Yes. Something apparently went wrong.
> 
> I would fix it, but can't do so quicky as the Oak documentation build is
> broken on Windows.
> 
>> This is particularly crucial as the Jackrabbit API is no longer published at 
>> https://jackrabbit.apache.org/api/trunk/. Publishing the javadoc is part of 
>> our release process documented at 
>> https://jackrabbit.apache.org/jcr/creating-releases.html#Part_II:_after_the_release_vote
>>  step 9 IIUC.
> 
> Well, that part is about Jackrabbit, not Oak.

Hm, IIUC the release documentation covers both Oak and Jackrabbit and step 9 is 
not for Jackrabbit particularly, it just mentions:

"If the release was a stable release for which we publish API docs”

That should be clarified if it only refers to Jackrabbit

> 
> AFAIU, the Oak side is happy to rely on javadoc.io, so does
> https://www.javadoc.io/doc/org.apache.jackrabbit/oak-jackrabbit-api/latest/index.html
> work for you maybe?

The problem is that there is no aggregate Javadoc and the links in 
https://jackrabbit.apache.org/oak/docs/oak_api/overview.html are lacking the 
javadoc.io link for oak-jackrabbit-api and still contain a link to 
https://jackrabbit.apache.org/oak/docs/apidocs/.

BTW: event https://jackrabbit.apache.org/oak/docs/ is neither the latest 
release (1.42) nor the latest snapshot (1.43-SNAPSHOT) but just an outdated 
snapshot. I don’t see that step documented though at 
https://jackrabbit.apache.org/jcr/creating-releases.html#Part_II:_after_the_release_vote.
 Is there another release process page for Oak?

> 
> Best regards, Julian

Javadocs

[Konrad Windszus]

Hi,
What happened to https://jackrabbit.apache.org/oak/docs/apidocs/?
It now only contains some shell script and options containing absolute 
filesystem paths from Marcel Reutegger's local machine 
(https://jackrabbit.apache.org/oak/docs/apidocs/options).
Can we publish the most recent release again?

This is particularly crucial as the Jackrabbit API is no longer published at 
https://jackrabbit.apache.org/api/trunk/. Publishing the javadoc is part of our 
release process documented at 
https://jackrabbit.apache.org/jcr/creating-releases.html#Part_II:_after_the_release_vote
 step 9 IIUC.

Thanks,
Konrad

Re: Property "rep:fullname" on rep:User nodes

[Konrad Windszus]

Thanks Angela for the quick answer. That was what I assumed.
Konrad

> On 19. Jan 2022, at 16:08, Angela Schreiber  wrote:
> 
> Hi Konrad
> 
> The default value doesn't make sense IMHO and should not have been added in 
> the first place.
> It is however covered by the node type of users/groups as they allow for 
> arbitrary properties being written below the user node (or some subtree for 
> that matter).
> 
> I would be a bit reluctant though to drop it without a compelling reason.
> If we conclude in the oak team that is likely not used anywhere and the 
> default value really bothers us, we can obviously drop it.
> 
> Kind regards
> Angela
> 
> From: Konrad Windszus 
> Sent: Wednesday, January 19, 2022 3:46 PM
> To: oak-dev@jackrabbit.apache.org 
> Subject: Property "rep:fullname" on rep:User nodes
> 
> Hi,
> In the default sync handler I found a mapping from "cn" to "rep:fullname" 
> (https://github.com/apache/jackrabbit-oak/blob/91a2b5aa48432ea5349499e8287ea05bcb02fada/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncConfigImpl.java#L91).
> 
> The property "rep:fullname" seems to be an arbitrary property name though, as 
> it is not part of the node type definition outlined at 
> https://jackrabbit.apache.org/oak/docs/security/user/default.html#Representation_in_the_Repository.
> Also I couldn't find this property name in the Oak codebase except for in the 
> default sync handler 
> (https://github.com/apache/jackrabbit-oak/search?q=rep%3Afullname).
> 
> Is there any reason why I should set this property in User nodes or does that 
> only exist for legacy reasons?
> Who is expected to read from this property?
> 
> Thanks,
> Konrad
> 

Property "rep:fullname" on rep:User nodes

[Konrad Windszus]

Hi,
In the default sync handler I found a mapping from "cn" to "rep:fullname" 
(https://github.com/apache/jackrabbit-oak/blob/91a2b5aa48432ea5349499e8287ea05bcb02fada/oak-auth-external/src/main/java/org/apache/jackrabbit/oak/spi/security/authentication/external/impl/DefaultSyncConfigImpl.java#L91).

The property "rep:fullname" seems to be an arbitrary property name though, as 
it is not part of the node type definition outlined at 
https://jackrabbit.apache.org/oak/docs/security/user/default.html#Representation_in_the_Repository.
Also I couldn't find this property name in the Oak codebase except for in the 
default sync handler 
(https://github.com/apache/jackrabbit-oak/search?q=rep%3Afullname).

Is there any reason why I should set this property in User nodes or does that 
only exist for legacy reasons?
Who is expected to read from this property?

Thanks,
Konrad

Re: Guava version update

[Konrad Windszus]

Hi Michał,
look at https://issues.apache.org/jira/browse/OAK-7182? 
 for details why upgrading is 
not that simple

Konrad

> On 18. Nov 2021, at 14:05, Michał Goliński  wrote:
> 
> Oak uses quite an old version of Guava. I've noticed some methods are used
> that were moved around a bit in Guava 21.0, but probably no extensive
> changes would be needed. What are the reasons for keeping Guava pegged at
> 15.0?
> 
> 
> Best regards
> 
> Michał Goliński

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Konrad Windszus]

I unfortunately am unable to vote as I constantly run into 
https://issues.apache.org/jira/browse/OAK-9497 when building 1.22.8 locally.
Any ideas how to debug that further?
Anyone else ever experienced the same issue?
Thanks,
Konrad

> On 15. Jul 2021, at 12:04, Andrei Dulceanu  wrote:
> 
> Hi,
> 
> A candidate for the Jackrabbit Oak 1.22.8 release is available at:
> 
>https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.8/
> 
> The release candidate is a zip archive of the sources in:
> 
> 
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.8/
> 
> The SHA1 checksum of the archive is
> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40.
> 
> 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.22.8
> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40
> 
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.8.
> 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.22.8
>[ ] -1 Do not release this package because...
> 
> Regards,
> Andrei

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Konrad Windszus]

I created https://issues.apache.org/jira/browse/JCR-4706 
<https://issues.apache.org/jira/browse/JCR-4706> to improve the 
release-check.sh in the future.
Won't have time to work on this right now, so I would be happy if someone else 
could pick it up.

> On 15. Jul 2021, at 12:57, Konrad Windszus  wrote:
> 
> For me the step 5 fails:
> 
> [INFO] 5. Compare svn tag with src zip contents
> [INFO] 
> [INFO]Exporting 
> https://github.com/apache/jackrabbit-oak/tags/jackrabbit-oak-1.22.8...
> svn: E175002: Unexpected HTTP status 504 'Gateway Timeout' on 
> '/apache/jackrabbit-oak/!svn/bc/125165/tags/jackrabbit-oak-1.22.8'
> 
> Never experienced that with any of the FileVault Git releases, so I wonder 
> whether this is a temporary thing with GitHub or that service does not scale 
> well with the size of the repo.
> 
> Konrad
> 
> 
> 
>> On 15. Jul 2021, at 12:04, Andrei Dulceanu  wrote:
>> 
>> Hi,
>> 
>> A candidate for the Jackrabbit Oak 1.22.8 release is available at:
>> 
>>   https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.8/
>> 
>> The release candidate is a zip archive of the sources in:
>> 
>> 
>> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.8/
>> 
>> The SHA1 checksum of the archive is
>> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40.
>> 
>> 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.22.8
>> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40
>> 
>> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.8.
>> 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.22.8
>>   [ ] -1 Do not release this package because...
>> 
>> Regards,
>> Andrei
> 

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Konrad Windszus]

For me the step 5 fails:

[INFO] 5. Compare svn tag with src zip contents
[INFO] 
[INFO]Exporting 
https://github.com/apache/jackrabbit-oak/tags/jackrabbit-oak-1.22.8...
svn: E175002: Unexpected HTTP status 504 'Gateway Timeout' on 
'/apache/jackrabbit-oak/!svn/bc/125165/tags/jackrabbit-oak-1.22.8'

Never experienced that with any of the FileVault Git releases, so I wonder 
whether this is a temporary thing with GitHub or that service does not scale 
well with the size of the repo.

Konrad



> On 15. Jul 2021, at 12:04, Andrei Dulceanu  wrote:
> 
> Hi,
> 
> A candidate for the Jackrabbit Oak 1.22.8 release is available at:
> 
>https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.8/
> 
> The release candidate is a zip archive of the sources in:
> 
> 
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.8/
> 
> The SHA1 checksum of the archive is
> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40.
> 
> 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.22.8
> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40
> 
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.8.
> 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.22.8
>[ ] -1 Do not release this package because...
> 
> Regards,
> Andrei

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Konrad Windszus]

> 
> Also
>>>   # run in SVN checkout of
>>> https://dist.apache.org/repos/dist/dev/jackrabbit
>> Is no longer applicable.
> 
> 
> This is exactly how I did it, by adding the release candidate zips to that
> svn repository. What should be done instead? Are there instructions for
> this somewhere and I forgot to read them?
> 
> I just followed the release instructions from here:
> https://jackrabbit.apache.org/jcr/creating-releases.html#Steps_to_build_the_release_artifacts
> 

Sorry, my bad. This still correct!
Konrad

Re: [VOTE] Release Apache Jackrabbit Oak 1.22.8

[Konrad Windszus]

Hi Andrei,
You need to adjust the vote template. The sources are not at 
https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.8/ 
  
but instead at 
https://github.com/apache/jackrabbit-oak/tree/jackrabbit-oak-1.22.8 
.

Also 
># run in SVN checkout of
> https://dist.apache.org/repos/dist/dev/jackrabbit

Is no longer applicable.

Konrad 

> On 15. Jul 2021, at 12:04, Andrei Dulceanu  wrote:
> 
> Hi,
> 
> A candidate for the Jackrabbit Oak 1.22.8 release is available at:
> 
>https://dist.apache.org/repos/dist/dev/jackrabbit/oak/1.22.8/
> 
> The release candidate is a zip archive of the sources in:
> 
> 
> https://svn.apache.org/repos/asf/jackrabbit/oak/tags/jackrabbit-oak-1.22.8/
> 
> The SHA1 checksum of the archive is
> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40.
> 
> 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.22.8
> 7ef907eee832e254b9ec07703cc4c8d4b7fcdf40
> 
> Please vote on releasing this package as Apache Jackrabbit Oak 1.22.8.
> 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.22.8
>[ ] -1 Do not release this package because...
> 
> Regards,
> Andrei

Re: Outdated 1.22 branch

[Konrad Windszus]

Look at https://stackoverflow.com/a/23719418

> Am 14.07.2021 um 15:42 schrieb Andrei Dulceanu :
> 
> Hi Konrad, Julian,
> 
> Thank you for your replies! I somehow ended up looking in pom.xml for trunk
> in svn as well and messed up all the info I had in my head :)
> 
> Now is clear your recommendation, but still don't know what to put inside
> ? Should it still be `HEAD`? Why?
> 
> Regards,
> Andrei
> 
>> On Wed, Jul 14, 2021 at 4:27 PM Konrad Windszus  wrote:
>> 
>> Exactly, you need to backport the scm changes in all pom.xmls from
>> https://issues.apache.org/jira/browse/OAK-9440 <
>> https://issues.apache.org/jira/browse/OAK-9440> to other branches if you
>> want to cut releases from them.
>> Konrad
>> 
>>>> On 14. Jul 2021, at 15:02, Julian Sedding  wrote:
>>> 
>>> Hi Andrei
>>> 
>>> I assume you would need to adjust the SCM Info in the pom of the
>>> "1.22" branch in Git (compare with the pom in "trunk" branch). The SVN
>>> branches are dead after migration to Git AFAIK.
>>> 
>>> I don't know if other adjustments are required. Konrad would likely know.
>>> 
>>> Regards
>>> Julian
>>> 
>>> On Wed, Jul 14, 2021 at 2:44 PM Andrei Dulceanu 
>> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> I have a quick question for you: are all Oak svn branches still updated
>>>> after migration to Git?
>>>> 
>>>> I’m trying to cut 1.22.8 release and obviously it fails if I try it
>> under
>>>> git checkout, so I moved in the svn checkout, but then this seems
>> outdated:
>>>> 
>>>> jackrabbit-oak-1-22 dulceanu$ svn log -l 1
>>>> 
>>>> r1888717 | mreutegg | 2021-04-13 12:58:52 +0300 (Tue, 13 Apr 2021) | 3
>>>> linesOAK-9393: Release Oak 1.22.7Fix version of oak-doc and
>>>> oak-doc-railroad-macro after release
>>>> 
>>>> 
>>>> I quickly checked what’s the status for trunk and this one is
>> up-to-date:
>>>> 
>>>> jackrabbit-oak dulceanu$ svn log -l 1
>>>> 
>>>> r1890974 | miroslav | 2021-06-22 18:33:17 +0300 (Tue, 22 Jun 2021) | 1
>>>> lineOAK-9469 in case of the timeout in AzureRepositoryLock, retry
>>>> renewing the lease
>>>> 
>>>> 
>>>> How can I progress with cutting 1.22.8 release? Any ideas?
>>>> 
>>>> Regards,
>>>> Andrei
>> 
>> 

Re: Outdated 1.22 branch

[Konrad Windszus]

> On 14. Jul 2021, at 14:44, Andrei Dulceanu  wrote:
> 
> I quickly checked what’s the status for trunk and this one is up-to-date:
> 
> jackrabbit-oak dulceanu$ svn log -l 1
> 
> r1890974 | miroslav | 2021-06-22 18:33:17 +0300 (Tue, 22 Jun 2021) | 1
> lineOAK-9469 in case of the timeout in AzureRepositoryLock, retry
> renewing the lease
> 


This is not up2date but the last commit before the migration. Compare with 
https://github.com/apache/jackrabbit-oak/commits/trunk 


Konrad

Re: Outdated 1.22 branch

[Konrad Windszus]

Exactly, you need to backport the scm changes in all pom.xmls from 
https://issues.apache.org/jira/browse/OAK-9440 
 to other branches if you want 
to cut releases from them.
Konrad

> On 14. Jul 2021, at 15:02, Julian Sedding  wrote:
> 
> Hi Andrei
> 
> I assume you would need to adjust the SCM Info in the pom of the
> "1.22" branch in Git (compare with the pom in "trunk" branch). The SVN
> branches are dead after migration to Git AFAIK.
> 
> I don't know if other adjustments are required. Konrad would likely know.
> 
> Regards
> Julian
> 
> On Wed, Jul 14, 2021 at 2:44 PM Andrei Dulceanu  wrote:
>> 
>> Hi all,
>> 
>> I have a quick question for you: are all Oak svn branches still updated
>> after migration to Git?
>> 
>> I’m trying to cut 1.22.8 release and obviously it fails if I try it under
>> git checkout, so I moved in the svn checkout, but then this seems outdated:
>> 
>> jackrabbit-oak-1-22 dulceanu$ svn log -l 1
>> 
>> r1888717 | mreutegg | 2021-04-13 12:58:52 +0300 (Tue, 13 Apr 2021) | 3
>> linesOAK-9393: Release Oak 1.22.7Fix version of oak-doc and
>> oak-doc-railroad-macro after release
>> 
>> 
>> I quickly checked what’s the status for trunk and this one is up-to-date:
>> 
>> jackrabbit-oak dulceanu$ svn log -l 1
>> 
>> r1890974 | miroslav | 2021-06-22 18:33:17 +0300 (Tue, 22 Jun 2021) | 1
>> lineOAK-9469 in case of the timeout in AzureRepositoryLock, retry
>> renewing the lease
>> 
>> 
>> How can I progress with cutting 1.22.8 release? Any ideas?
>> 
>> Regards,
>> Andrei

Re: Outdated 1.22 branch

[Konrad Windszus]

Hi Andrei,
No, SVN is read-only and no longer updated as outlined in 
https://issues.apache.org/jira/browse/OAK-9440.\ 

Konrad

> On 14. Jul 2021, at 14:44, Andrei Dulceanu  wrote:
> 
> Hi all,
> 
> I have a quick question for you: are all Oak svn branches still updated
> after migration to Git?
> 
> I’m trying to cut 1.22.8 release and obviously it fails if I try it under
> git checkout, so I moved in the svn checkout, but then this seems outdated:
> 
> jackrabbit-oak-1-22 dulceanu$ svn log -l 1
> 
> r1888717 | mreutegg | 2021-04-13 12:58:52 +0300 (Tue, 13 Apr 2021) | 3
> linesOAK-9393: Release Oak 1.22.7Fix version of oak-doc and
> oak-doc-railroad-macro after release
> 
> 
> I quickly checked what’s the status for trunk and this one is up-to-date:
> 
> jackrabbit-oak dulceanu$ svn log -l 1
> 
> r1890974 | miroslav | 2021-06-22 18:33:17 +0300 (Tue, 22 Jun 2021) | 1
> lineOAK-9469 in case of the timeout in AzureRepositoryLock, retry
> renewing the lease
> 
> 
> How can I progress with cutting 1.22.8 release? Any ideas?
> 
> Regards,
> Andrei

Re: [RESULT] [VOTE] Migrate to Git

[Konrad Windszus]

Hi everyone,
The repository has been successfully migrated and the patches and PR were 
applied. Now the documentation should be up2date.
For details refer to https://issues.apache.org/jira/browse/OAK-9440.

Please consider https://jackrabbit.apache.org/oak/docs/developing-with-git.html 
if you never worked with ASF/GitHub before.
Konrad

> On 21. Jun 2021, at 13:21, Marcel Reutegger  
> wrote:
> 
> Hi Konrad
> 
> On 18.06.21, 11:01, "Konrad Windszus"  wrote:
>> I haven't received any feedback on the patches or the PR, I therefore
>> defer migration for one week. Please have a look at
>> https://issues.apache.org/jira/browse/OAK-9440 and the attached patches
>> and PR
> 
> Thanks for preparing those changes. They look good to me.
> 
> Regards
> Marcel
> 

Re: [RESULT] [VOTE] Migrate to Git

[Konrad Windszus]

I haven't received any feedback on the patches or the PR, I therefore defer 
migration for one week.
Please have a look at https://issues.apache.org/jira/browse/OAK-9440 
<https://issues.apache.org/jira/browse/OAK-9440> and the attached patches and PR

Thanks,
Konrad

> On 2. Jun 2021, at 16:59, Konrad Windszus  wrote:
> 
> Hi,
> Here are some updates regarding the migration:
> 
> 1) I provided a (draft) PR in 
> https://github.com/apache/jackrabbit-oak/pull/296 with the necessary fixes 
> for the Oak source code and the Oak documentation site. Please have a look.
> 
> 2) For http://jackrabbit.apache.org/jcr/creating-releases.html there is a 
> patch attached to https://issues.apache.org/jira/browse/OAK-9440
> 
> 3) For https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh 
> there is a patch attached to  https://issues.apache.org/jira/browse/OAK-9440 
> as well.
> 
> 4) I would propose to get rid of https://jackrabbit.apache.org/oak/index.html 
> and instead just redirect to 
> https://jackrabbit.apache.org/oak/docs/index.html as the latter provides all 
> relevant information and the former is really manually maintained HTML 
> AFAICS. Please tell me in case you think the HTML at 
> https://jackrabbit.apache.org/oak/index.html is worth keeping.
> 
> Is there anything else which I might have missed?
> 
> Konrad
> 
> 
>> On 25. May 2021, at 18:42, Konrad Windszus  wrote:
>> 
>> The vote passes with the following result:
>> 
>> +1 (binding): Marcel, Matt and myself.
>> 
>> I propose to do the change in CW 24 (14th -18th of June). That should give 
>> us all enough time to prepare for the switch (which is done by ASF INFRA).
>> Since the SVN will stay (with read-only access) we shouldn't break any 
>> downstream build jobs. But those will obviously only get the new changes 
>> once they switch to Git.
>> No need to do it in a big bang though, so hopefully agreeing on a week is 
>> enough (as it is hard to align with INFRA on one specific day)
>> 
>> I am gonna prepare PRs already for documentation updates and the necessary 
>> changes for the pom.xmls, so everyone can review prior to the migration and 
>> we can merge them afterwards.
>> Konrad
>> 
>> 
>>> On 19. May 2021, at 09:24, Konrad Windszus  wrote:
>>> 
>>> Hi,
>>> in 
>>> https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
>>>  we discussed moving to Git. After the successful migration of FileVault to 
>>> Git we should tackle Oak as well.
>>> I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
>>> hereby propose to
>>> 
>>> 1. migrate the SVN repository at 
>>> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
>>> "jackrabbit-oak"
>>> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
>>> mirror the new native Git repo (at Gitbox)
>>> 3. change the main branch name from "trunk" to "main"
>>> 4. make the SVN repository read only
>>> 
>>> Vote is open for 72 hours.
>>> [ ] +1, migrate Oak to Git
>>> [ ] 0
>>> [ ] -1, because...
>>> 
>>> 
>>> The actual work is tracked in 
>>> https://issues.apache.org/jira/browse/OAK-9440. 
>>> 
>>> Thanks,
>>> Konrad
>> 
> 

Re: [RESULT] [VOTE] Migrate to Git

[Konrad Windszus]

Hi,
Here are some updates regarding the migration:

1) I provided a (draft) PR in https://github.com/apache/jackrabbit-oak/pull/296 
with the necessary fixes for the Oak source code and the Oak documentation 
site. Please have a look.

2) For http://jackrabbit.apache.org/jcr/creating-releases.html there is a patch 
attached to https://issues.apache.org/jira/browse/OAK-9440

3) For https://dist.apache.org/repos/dist/dev/jackrabbit/check-release.sh there 
is a patch attached to  https://issues.apache.org/jira/browse/OAK-9440 as well.

4) I would propose to get rid of https://jackrabbit.apache.org/oak/index.html 
and instead just redirect to https://jackrabbit.apache.org/oak/docs/index.html 
as the latter provides all relevant information and the former is really 
manually maintained HTML AFAICS. Please tell me in case you think the HTML at 
https://jackrabbit.apache.org/oak/index.html is worth keeping.

Is there anything else which I might have missed?

Konrad


> On 25. May 2021, at 18:42, Konrad Windszus  wrote:
> 
> The vote passes with the following result:
> 
> +1 (binding): Marcel, Matt and myself.
> 
> I propose to do the change in CW 24 (14th -18th of June). That should give us 
> all enough time to prepare for the switch (which is done by ASF INFRA).
> Since the SVN will stay (with read-only access) we shouldn't break any 
> downstream build jobs. But those will obviously only get the new changes once 
> they switch to Git.
> No need to do it in a big bang though, so hopefully agreeing on a week is 
> enough (as it is hard to align with INFRA on one specific day)
> 
> I am gonna prepare PRs already for documentation updates and the necessary 
> changes for the pom.xmls, so everyone can review prior to the migration and 
> we can merge them afterwards.
> Konrad
> 
> 
>> On 19. May 2021, at 09:24, Konrad Windszus  wrote:
>> 
>> Hi,
>> in 
>> https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
>>  we discussed moving to Git. After the successful migration of FileVault to 
>> Git we should tackle Oak as well.
>> I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
>> hereby propose to
>> 
>> 1. migrate the SVN repository at 
>> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
>> "jackrabbit-oak"
>> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
>> mirror the new native Git repo (at Gitbox)
>> 3. change the main branch name from "trunk" to "main"
>> 4. make the SVN repository read only
>> 
>> Vote is open for 72 hours.
>> [ ] +1, migrate Oak to Git
>> [ ] 0
>> [ ] -1, because...
>> 
>> 
>> The actual work is tracked in 
>> https://issues.apache.org/jira/browse/OAK-9440. 
>> 
>> Thanks,
>> Konrad
> 

[RESULT] [VOTE] Migrate to Git

[Konrad Windszus]

The vote passes with the following result:

+1 (binding): Marcel, Matt and myself.

I propose to do the change in CW 24 (14th -18th of June). That should give us 
all enough time to prepare for the switch (which is done by ASF INFRA).
Since the SVN will stay (with read-only access) we shouldn't break any 
downstream build jobs. But those will obviously only get the new changes once 
they switch to Git.
No need to do it in a big bang though, so hopefully agreeing on a week is 
enough (as it is hard to align with INFRA on one specific day)

I am gonna prepare PRs already for documentation updates and the necessary 
changes for the pom.xmls, so everyone can review prior to the migration and we 
can merge them afterwards.
Konrad


> On 19. May 2021, at 09:24, Konrad Windszus  wrote:
> 
> Hi,
> in 
> https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
>  we discussed moving to Git. After the successful migration of FileVault to 
> Git we should tackle Oak as well.
> I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
> hereby propose to
> 
> 1. migrate the SVN repository at 
> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
> "jackrabbit-oak"
> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
> mirror the new native Git repo (at Gitbox)
> 3. change the main branch name from "trunk" to "main"
> 4. make the SVN repository read only
> 
> Vote is open for 72 hours.
> [ ] +1, migrate Oak to Git
> [ ] 0
> [ ] -1, because...
> 
> 
> The actual work is tracked in https://issues.apache.org/jira/browse/OAK-9440. 
> 
> Thanks,
> Konrad

Re: [VOTE] Migrate to Git

[Konrad Windszus]

Here is my +1

Konrad

> On 19. May 2021, at 09:24, Konrad Windszus  wrote:
> 
> Hi,
> in 
> https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
>  we discussed moving to Git. After the successful migration of FileVault to 
> Git we should tackle Oak as well.
> I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
> hereby propose to
> 
> 1. migrate the SVN repository at 
> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
> "jackrabbit-oak"
> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
> mirror the new native Git repo (at Gitbox)
> 3. change the main branch name from "trunk" to "main"
> 4. make the SVN repository read only
> 
> Vote is open for 72 hours.
> [ ] +1, migrate Oak to Git
> [ ] 0
> [ ] -1, because...
> 
> 
> The actual work is tracked in https://issues.apache.org/jira/browse/OAK-9440. 
> 
> Thanks,
> Konrad

Re: [VOTE] Migrate to Git

[Konrad Windszus]

The only reason being that 'trunk' sound pretty much like SVN and 'main' is 
more in line with git standards, but we can also defer/skip that.
Konrad

> On 19. May 2021, at 16:35, Matt Ryan  wrote:
> 
> What's the reason for #3 - changing the main branch name from "trunk" to
> "main"?  I'm not particularly opposed, but it seems to me "trunk" works
> just fine as a name - is there a specific reason to rename?
> 
> 
> -MR
> 
> On Wed, May 19, 2021 at 3:13 AM Konrad Windszus  wrote:
> 
>> Currently the page at
>> http://jackrabbit.apache.org/jcr/creating-releases.html <
>> http://jackrabbit.apache.org/jcr/creating-releases.html> only refers to
>> Jackrabbit 2 and Oak releases. FileVault releases have never been
>> documented there as they have slight differences. I will add a link though
>> to the jackrabbit documentation.
>> In the context of https://issues.apache.org/jira/browse/OAK-9440 <
>> https://issues.apache.org/jira/browse/OAK-9440> this page may need some
>> updates, but again, the handling with dist stays the same (still SVN) and
>> maven-release-plugin takes care of the rest, so currently I don't see any
>> changes necessary on the actual release steps (only on some links,
>> additional explanation, )
>> 
>> Konrad
>> 
>>> On 19. May 2021, at 11:03, Julian Reschke  wrote:
>>> 
>>> Am 19.05.2021 um 10:56 schrieb Konrad Windszus:
>>>> Releasing FileVault works as before (as maven-release-plugin deals with
>> Git/SVN). The steps are documented at
>> http://jackrabbit.apache.org/filevault/howto_release.html and
>> https://jackrabbit.apache.org/filevault-package-maven-plugin/howto_release.html
>> .
>>>> Konrad
>>>> ...
>>> 
>>> Ah, that is already a fork of the "main" page.
>>> 
>>> So, if I understand correctly, most steps are indeed the same, as the
>>> actual release still goes into Apache SVN.
>>> 
>>> If this is the case, it would be good if we could update that page so
>>> that it is correct both for SVN and GIT.
>>> 
>>> Best regards, Julian
>> 
>> 

Re: [VOTE] Migrate to Git

[Konrad Windszus]

Currently the page at http://jackrabbit.apache.org/jcr/creating-releases.html 
<http://jackrabbit.apache.org/jcr/creating-releases.html> only refers to 
Jackrabbit 2 and Oak releases. FileVault releases have never been documented 
there as they have slight differences. I will add a link though to the 
jackrabbit documentation.
In the context of https://issues.apache.org/jira/browse/OAK-9440 
<https://issues.apache.org/jira/browse/OAK-9440> this page may need some 
updates, but again, the handling with dist stays the same (still SVN) and 
maven-release-plugin takes care of the rest, so currently I don't see any 
changes necessary on the actual release steps (only on some links, additional 
explanation, )

Konrad

> On 19. May 2021, at 11:03, Julian Reschke  wrote:
> 
> Am 19.05.2021 um 10:56 schrieb Konrad Windszus:
>> Releasing FileVault works as before (as maven-release-plugin deals with 
>> Git/SVN). The steps are documented at 
>> http://jackrabbit.apache.org/filevault/howto_release.html and 
>> https://jackrabbit.apache.org/filevault-package-maven-plugin/howto_release.html.
>> Konrad
>> ...
> 
> Ah, that is already a fork of the "main" page.
> 
> So, if I understand correctly, most steps are indeed the same, as the
> actual release still goes into Apache SVN.
> 
> If this is the case, it would be good if we could update that page so
> that it is correct both for SVN and GIT.
> 
> Best regards, Julian

Re: [VOTE] Migrate to Git

[Konrad Windszus]

Releasing FileVault works as before (as maven-release-plugin deals with 
Git/SVN). The steps are documented at 
http://jackrabbit.apache.org/filevault/howto_release.html and 
https://jackrabbit.apache.org/filevault-package-maven-plugin/howto_release.html.
Konrad

> On 19. May 2021, at 10:53, Julian Reschke  wrote:
> 
> Am 19.05.2021 um 09:35 schrieb Konrad Windszus:
>> TBH: I tried to initiate the discussion two years ago and there was no 
>> reaction: 
>> https://lists.apache.org/thread.html/4ada22cf37faf7e865e4d33451fe14d34d67846824a86dfdbb150d9e%40%3Coak-dev.jackrabbit.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/4ada22cf37faf7e865e4d33451fe14d34d67846824a86dfdbb150d9e@%3Coak-dev.jackrabbit.apache.org%3E>,
>>  but feel free to raise any concerns in this thread.
>> ...
> 
> I though the concern was clear.
> 
> Changing the version control system affects how releases are made. Thus,
> this requires support from those who currently do the releases (which
> does not include me right now).
> 
> A good first step would be to document what works for VLT right now -
> could that process be included into
> <http://jackrabbit.apache.org/jcr/creating-releases.html>? Or if this is
> too messay, could you create a separate version for projects on Git?
> 
> Best regards, Julian

Re: [VOTE] Migrate to Git

[Konrad Windszus]

TBH: I tried to initiate the discussion two years ago and there was no 
reaction: 
https://lists.apache.org/thread.html/4ada22cf37faf7e865e4d33451fe14d34d67846824a86dfdbb150d9e%40%3Coak-dev.jackrabbit.apache.org%3E
 
<https://lists.apache.org/thread.html/4ada22cf37faf7e865e4d33451fe14d34d67846824a86dfdbb150d9e@%3Coak-dev.jackrabbit.apache.org%3E>,
 but feel free to raise any concerns in this thread.

> On 19. May 2021, at 09:32, Julian Reschke  wrote:
> 
> Am 19.05.2021 um 09:24 schrieb Konrad Windszus:
>> Hi,
>> in 
>> https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
>>  we discussed moving to Git. After the successful migration of FileVault to 
>> Git we should tackle Oak as well.
>> I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
>> hereby propose to
>> 
>> 1. migrate the SVN repository at 
>> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
>> "jackrabbit-oak"
>> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
>> mirror the new native Git repo (at Gitbox)
>> 3. change the main branch name from "trunk" to "main"
>> 4. make the SVN repository read only
>> 
>> Vote is open for 72 hours.
>> [ ] +1, migrate Oak to Git
>> [ ] 0
>> [ ] -1, because...
>> 
>> 
>> The actual work is tracked in https://issues.apache.org/jira/browse/OAK-9440.
> 
> FWIW, this *really* needs suport from those who currently do the Release
> Management, because it affects them more than others.
> 
> As such I would not recommend to have a vote until this has been
> discussed among the current RMs.
> 
> Best regards, Julian

Re: [VOTE] Migrate to Git

[Konrad Windszus]

Just to clarify: for now I would just migrate to one Git repository hosting all 
Oak modules. We can further split it up if there is a need later on.

> On 19. May 2021, at 09:24, Konrad Windszus  wrote:
> 
> Hi,
> in 
> https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
>  we discussed moving to Git. After the successful migration of FileVault to 
> Git we should tackle Oak as well.
> I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
> hereby propose to
> 
> 1. migrate the SVN repository at 
> https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
> "jackrabbit-oak"
> 2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
> mirror the new native Git repo (at Gitbox)
> 3. change the main branch name from "trunk" to "main"
> 4. make the SVN repository read only
> 
> Vote is open for 72 hours.
> [ ] +1, migrate Oak to Git
> [ ] 0
> [ ] -1, because...
> 
> 
> The actual work is tracked in https://issues.apache.org/jira/browse/OAK-9440. 
> 
> Thanks,
> Konrad

[VOTE] Migrate to Git

[Konrad Windszus]

Hi,
in 
https://lists.apache.org/thread.html/8ea0d827d9e8488183648f2364ecd4e178b6d82e03193735aae6b5cd%40%3Coak-dev.jackrabbit.apache.org%3E
 we discussed moving to Git. After the successful migration of FileVault to Git 
we should tackle Oak as well.
I am volunteering to trigger the actual work (mostly on ASF INFRA side). I 
hereby propose to

1. migrate the SVN repository at 
https://svn.apache.org/repos/asf/jackrabbit/oak/ to a Git repository named 
"jackrabbit-oak"
2. migrate GitHub SVN mirror at https://github.com/apache/jackrabbit-oak to 
mirror the new native Git repo (at Gitbox)
3. change the main branch name from "trunk" to "main"
4. make the SVN repository read only

Vote is open for 72 hours.
[ ] +1, migrate Oak to Git
[ ] 0
[ ] -1, because...


The actual work is tracked in https://issues.apache.org/jira/browse/OAK-9440. 

Thanks,
Konrad

Re: Why don't we move to Git?

[Konrad Windszus]

Almost two years later, I volunteer to do the move. I am gonna start a vote in 
a separate thread.

On 2019/07/23 17:15:03, Konrad Windszus  wrote: 
> Was there any consensus reached and is it planned to be tackled soon?
> 
> On 2018/12/12 23:35:42, Matt Ryan  wrote: 
> > I'm +1; as Davide said, after Christmas :)
> > 
> > Working out details seems like a good topic for an upcoming Oakathon,
> > assuming the general feeling is in favor of the change.
> > 
> > -MR
> > 
> > On Mon, Dec 10, 2018 at 2:58 AM Francesco Mari 
> > wrote:
> > 
> > > Given the recent announcement about gitbox.apache.org, the seamless
> > > integration with GitHub, and the fact that many of us already work with 
> > > Git
> > > in our daily workflow, what about moving our repositories to Git?
> > >
> > 
> 

Re: [filevault] Installing users and access control entries in the same package

[Konrad Windszus]

I would suggest to split it up into two packages and make the ACL package 
depend on the user package. You can even put those two packages into a common 
container package. The dependencies will enforce the right installation order.
Konrad

> Am 21.08.2020 um 18:47 schrieb Robert Munteanu :
> 
> Hi,
> 
> I am trying to install a content package that includes:
> 
> - two users under /home/users/slingshot
> - content with ACEs that reference the two users under
> /content/slingshot
> 
> When installing the content packages I see that the /content entry is
> processed first, leading to errors like
> 
>  E  /content/slingshot/users/slingshot1/rep:policy
>  ! org.xml.sax.SAXException:
> javax.jcr.security.AccessControlException: Unknown principal slingshot1
> javax.jcr.security.AccessControlException: Unknown principal slingshot1
> 
> and only later on is the user created
> 
>  -  /home
>  -  /home/users
>  A  /home/users/slingshot
>  A  /home/users/slingshot/slingshot1
> 
> Obviously, reinstalling the content package fixes the problem but I'm
> looking for a more error-safe way of installing the content package.
> 
> How can I install this content package with users and ACEs from without
> errors?
> 
> Thanks,
> Robert
> 

Re: [filevault-package-maven-plugin] Packaging additional files in META-INF

[Konrad Windszus]

Hi Robert,
Currently the filevault-package-maven-plugin creates packages from mainly two 
different source directories:

https://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#jcrRootSourceDirectory
 

 -> ends up in the installed package
https://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#metaInfVaultDirectory
 

 -> ends up in META-INF/vault

Probably we need an optional third source to put META-INF somewhere outside the 
vault directory.
Feel free to raise a JIRA.

Thanks,
Konrad


> On 21. Aug 2020, at 11:33, Robert Munteanu  wrote:
> 
> Hi,
> 
> I am trying to use the filevault-package-maven-plugin with a Sling
> project. By default, artifacts are checked to see if they have legal
> files: META-INF/{LICENSE,NOTICE}.
> 
> When building a content package these are not included.  I've
> configured the plug-in with:
> 
> 
>org.apache.jackrabbit
>filevault-package-maven-plugin
>1.1.4
>true
>
>${project.build.outputDirectory} otSourceDirectory>
>
> 
> 
> The legal files from target/classes are understandably skipped since
> they don't match the filter defintions, so that's not a good place for
> them. What I would like is to have then copied over to META-INF in the
> resulting content package, but I did not find an easy way to do this.
> 
> I worked around it with an additional resources plug-in execution:
> 
> 
>maven-resources-plugin
>
>
>copy-legal-files
>prepare-package
>
>copy-resources
>
>
>
> ${project.build.directory}/vault-work/META-INF
>
>
>
> ${project.build.directory}/maven-shared-archive-resources/META-INF/
>
>
>
>
>
> 
> 
> Is there a simpler way to copy files to META-INF/ using the plug-in?
> 
> Thanks,
> Robert
> 

Re: JCR 2.0 System View -> sv:name: expanded or qualified form?

[Konrad Windszus]

So what you are saying is basically that the part inside the {} must contain at 
least one InvalidChar 
(https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2%20Names
 <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2 
Names>) to make Jackrabbit/Oak detect it as a expanded name?
Why was the default namespace URI then defined as the empty string? That sounds 
like a mistake to me.

Currently I cannot even do NameParser.parse() 
(https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53
 
<https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi-commons/src/main/java/org/apache/jackrabbit/spi/commons/conversion/NameParser.java#L53>)
 for name = "wrongtype".
It throws an IllegalArgumentException:

java.lang.IllegalArgumentException: No namespaceURI specified
at 
org.apache.jackrabbit.spi.commons.name.NameFactoryImpl.create(NameFactoryImpl.java:49)
at 
org.apache.jackrabbit.spi.commons.conversion.NameParser.parse(NameParser.java:191)

with jackrabbit-spi-commons 2.20.0.

"wrongtype" is IMHO a totally valid qualified name, therefore it shouldn't 
throw!
Is this a bug?

Konrad


> On 11. Feb 2020, at 15:40, Julian Reschke  wrote:
> 
> On 11.02.2020 12:17, Konrad Windszus wrote:
>> What should be the expanded name for the qualified name "foo" (without URI 
>> prefix) then?
> 
> One could either say that there is none (and you don't need one), or
> that it is "foo" (and raise a bug against the spec to say that missing
> leading "{..." in an expanded name implies the empty namespace.
> 
>> What namespace URI should be used then?
> 
> If "foo" is in no namespace, and you need a namespace name, it would be
> the empty string.
> 
>> I am now totally lost to be honest.
> 
> Yes, it's confusing.
> 
> It's because in JCR 2.0, expanded names were introduced as an alternate
> name notation, and we had to find a way not to let expanded names to
> conflict with qualified names.
> 
> The only way to make this work was to require the namespace name not to
> be empty and to be a valid URI (which implies there's at least one ":"
> in the namespace name).
> 
> Best regards, Julian

Re: JCR 2.0 System View -> sv:name: expanded or qualified form?

[Konrad Windszus]

What should be the expanded name for the qualified name "foo" (without URI 
prefix) then?
What namespace URI should be used then?

I am now totally lost to be honest.
Konrad

> On 11. Feb 2020, at 12:01, Julian Reschke  wrote:
> 
> On 11.02.2020 11:52, Konrad Windszus wrote:
>> According to
>> https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces
>> <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1
>> Namespaces> an empty URI part is totally valid and should be used for
>> non-namespaced names!
>> ...
> 
> I would call that a bug in the spec, at least in the context of expanded
> names.
> 
> At the end of the day, "{}foo" is a valid local name, so it can't by
> definition not also be an expanded name.
> 
> Best regards, Julian

Re: JCR 2.0 System View -> sv:name: expanded or qualified form?

[Konrad Windszus]

According to 
https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1%20Namespaces
 <https://docs.adobe.com/docs/en/spec/jcr/2.0/3_Repository_Model.html#3.2.1 
Namespaces> an empty URI part is totally valid and should be used for 
non-namespaced names!

> On 11. Feb 2020, at 11:50, Julian Reschke  wrote:
> 
> On 11.02.2020 11:45, Konrad Windszus wrote:
>> Also according to 
>> https://github.com/apache/jackrabbit/blob/b23d6734381e49f236c3705820126803555608b5/jackrabbit-spi/src/main/java/org/apache/jackrabbit/spi/Name.java#L39
>>  the default namespace URI is the empty one!
> 
> But that constant does not affect the name format
> 
>>> On 11. Feb 2020, at 11:43, Konrad Windszus  wrote:
>>> 
>>> But I am generating this expanded form via
>>> DefaultNamePathResolver.getQName("newnode")
>>> 
>>> This returns a org.apache.jackrabbit.spi.Name, whose toString() returns 
>>> "{}newnode".
>>> Is the Name being returned by getQName then being wrong?
> 
> Yes, please open a ticket.
> 
> Best regards, Julian

Re: [DISCUSS] Branching and release: version numbers

[Konrad Windszus]

Semantic Versioning mandates not only package version changes but also bundle 
version changes. Compare with 
https://www.osgi.org/developer/white-papers/semantic-versioning/bundles-and-fragments/
 


" The version of a bundle must therefore semantically aggregate the semantics 
of all its constituent packages. If any of these packages are incompatible with 
its providers then the bundle version must increment the minor version. If any 
of these packages are incompatible with consumers, the bundle version must 
increment the major version."

This is sometimes conflicting with odd/even versions: 
https://github.com/bndtools/bnd/issues/3446 


Konrad

> On 30. Sep 2019, at 12:09, Marcel Reutegger  
> wrote:
> 
> Hi,
> 
> In my view, using an odd numbered snapshot version would be better
> as well. According to versionatorr, OSGi will consider 1.20-SNAPSHOT
> more recent than 1.20.0.
> 
> http://versionatorr.appspot.com/?a=1.20-SNAPSHOT&b=1.20.0
> 
> Regards
> Marcel
> 
> On 27.09.19, 11:57, "Julian Reschke"  wrote:
> 
>On 04.03.2019 14:29, Davide Giannella wrote:
>> ...
> 
>Picking up an old thread...
> 
>So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next 
> week.
> 
>What we apparently did not discuss what the project version for trunk
>should be in the meantime.
> 
>So far, we've been using 1.12-SNAPSHOT, etc, and we are on 1.20-SNAPHOT
>right now.
> 
>This however seems incorrect to me; shouldn't it be 1.19-SNAPSHOT?
> 
>For this release I'd like to avoid any changes, but for future releases
>I'd like to document that we're using an odd-numbered version.
> 
>Feedback appreciated,
> 
>Julian
> 
> 
> 

Re: Content Package - Check for new index definitions

[Konrad Windszus]

Thanks for the input.

Although this is easy to determine for new/modified index definitions, this is 
impossible to tell for paths below /oak:index which are just getting removed 
(i.e. are just listed in the filter). I guess for the latter we have to assume 
the worst, case i.e. that an existing index definition is removed.

> On 26. Jul 2019, at 09:37, Jörg Hoh  wrote:
> 
> Hi Konrad,
> 
> As written in JCRVLT-345, I don't think that we should add a lot of
> validation features into the filevault-package-m-p, as validation can
> happen more often during the lifetime of a package (e.g. before deployment
> if developer and deployer/operation are not identical). I would move all
> validations into a dedicated plugin.
> 
> Regarding your question: It does not matter what type of index, so b). You
> can identify these nodes simply by looking at the node-types. All non-index
> definitions should be ignored in this validation.
> 
> Jörg
> 
> Am Mi., 24. Juli 2019 um 12:14 Uhr schrieb Konrad Windszus > :
> 
>> Hi,
>> the filevault-package-maven-plugin validates if a package contains a new
>> index definition. This behaviour can be disabled via the
>> "allowIndexDefinitions" parameter (
>> https://jackrabbit.apache.org/filevault-package-maven-plugin/generate-metadata-mojo.html#allowIndexDefinitions)
>> . There was a bug recently reported about that at
>> https://issues.apache.org/jira/browse/JCRVLT-343?focusedCommentId=16891508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16891508
>> because there was a rep:policy node modified below oak:index. It is not
>> 100% clear under which circumstances the validation should fail:
>> a) only for synchronous index definition nodes
>> b) for all index node definitions
>> c) for all changes below /oak:index
>> 
>> I tend to say actually only a) might lead to issues and therefore only
>> those nodes should make the build optionally fail.
>> WDYT?
>> 
>> Thanks,
>> Konrad
> 
> 
> 
> -- 
> Cheers,
> Jörg Hoh,
> 
> http://cqdump.wordpress.com
> Twitter: @joerghoh

Re: New Jackrabbit Committer: Konrad Windszus

[Konrad Windszus]

Hi everyone,
thanks a lot for having invited me.
Some words about myself: I have experience with AEM/CQ since 2005. I am now 
working for Netcentric. I joined the Apache family in 2014 by becoming an 
Apache Sling committer. Meanwhile I am part of the Apache Sling PMC.

I am looking forward to contribute even more in the future to Jackrabbit/Oak. 
Particularly I am interested in improving Filevault and the related Maven 
Plugin.

Konrad


> On 24. Jul 2019, at 15:37, Marcel Reutegger  wrote:
> 
> Hi,
> 
> Please welcome Konrad Windszus as a new committer and PMC member of
> the Apache Jackrabbit project. The Jackrabbit PMC recently decided to
> offer Konrad 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, Konrad!
> 
> Regards
> Marcel
> 

Content Package - Check for new index definitions

[Konrad Windszus]

Hi, 
the filevault-package-maven-plugin validates if a package contains a new index 
definition. This behaviour can be disabled via the "allowIndexDefinitions" 
parameter 
(https://jackrabbit.apache.org/filevault-package-maven-plugin/generate-metadata-mojo.html#allowIndexDefinitions)
 . There was a bug recently reported about that at 
https://issues.apache.org/jira/browse/JCRVLT-343?focusedCommentId=16891508&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16891508
 because there was a rep:policy node modified below oak:index. It is not 100% 
clear under which circumstances the validation should fail:
a) only for synchronous index definition nodes
b) for all index node definitions
c) for all changes below /oak:index

I tend to say actually only a) might lead to issues and therefore only those 
nodes should make the build optionally fail.
WDYT?

Thanks,
Konrad

Re: Why don't we move to Git?

[Konrad Windszus]

Was there any consensus reached and is it planned to be tackled soon?

On 2018/12/12 23:35:42, Matt Ryan  wrote: 
> I'm +1; as Davide said, after Christmas :)
> 
> Working out details seems like a good topic for an upcoming Oakathon,
> assuming the general feeling is in favor of the change.
> 
> -MR
> 
> On Mon, Dec 10, 2018 at 2:58 AM Francesco Mari 
> wrote:
> 
> > Given the recent announcement about gitbox.apache.org, the seamless
> > integration with GitHub, and the fact that many of us already work with Git
> > in our daily workflow, what about moving our repositories to Git?
> >
> 

Re: Production usage (and documentation) of FileBlobStore?

[Konrad Windszus]

I am wondering whether after 1,5 more years, there is any other input regarding 
using FileBlobStore over the FileDataStore wrapper?
I can see that in 
https://helpx.adobe.com/experience-manager/6-5/sites/deploying/using/data-store-config.html#DataStoreConfigurations
 the new FileBlobStore is no longer being mentioned.
Does that mean that FileBlobStore is (still) not production ready or has that 
option rather been abandoned?

Thanks for any input
Konrad


> On 14. Nov 2016, at 14:54, Konrad Windszus  wrote:
> 
> Can anyone share her/his experience with FileBlobStore? Otherwise I would 
> assume no one ever used that in production, which would be really sad.
> Konrad
> 
>> On 8 Nov 2016, at 10:17, Konrad Windszus  wrote:
>> 
>> The BlobStore is being mentioned as the new advanced way of using storing 
>> blobs in http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html 
>> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html>.
>> Unfortunately neither http://jackrabbit.apache.org/oak/docs/osgi_config.html 
>> <http://jackrabbit.apache.org/oak/docs/osgi_config.html> nor 
>> http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#SegmentNodeStore
>>  
>> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#SegmentNodeStore>
>>  or 
>> http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#DocumentNodeStore
>>  
>> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#DocumentNodeStore>
>>  list that as an option. Also it is not mentioned as being supported by the 
>> Blob Garbage Collection 
>> (http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Blob_Garbage_Collection
>>  
>> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Blob_Garbage_Collection>).
>> 
>> So the question is: Is it safe to use the FileBlobStore instead of the 
>> FileDataStore in production? When I tried 2 years ago I ran into 
>> https://issues.apache.org/jira/browse/OAK-1842 
>> <https://issues.apache.org/jira/browse/OAK-1842> which is now fixed. I am 
>> wondering whether that option is recommended to use for a production setup 
>> or whether that option is considered unstable (because it is also not 
>> mentioned in 
>> https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html
>>  
>> <https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html>)?
>> 
>> Thanks for any advice. 
>> Konrad
>> 
>> BTW it would be great if the documentation pages listed above could be a 
>> littlebit clearer in that regard.
> 

Re: Improving Oak Documentation

[Konrad Windszus]

I linked some related JIRA issues to [2]. They mostly refer to lack of OSGi 
configuration description (especially in the field of blob stores).
Konrad

> On 29 Mar 2017, at 11:55, Chetan Mehrotra  wrote:
> 
> Hi,
> 
> As a user of Oak or someone exploring Oak you might find certain
> aspects which are not documented properly in our Oak documentation
> [1]. To improve that we have created OAK-5998 [2]
> 
> Kindly add via comments the topics which you think need more clarity
> along with some details on what is missing and which specific aspect
> needs improvement.
> 
> Chetan Mehrotra
> [1] https://jackrabbit.apache.org/oak/docs
> [2] https://issues.apache.org/jira/browse/OAK-5998

Re: Production usage (and documentation) of FileBlobStore?

[Konrad Windszus]

Can anyone share her/his experience with FileBlobStore? Otherwise I would 
assume no one ever used that in production, which would be really sad.
Konrad

> On 8 Nov 2016, at 10:17, Konrad Windszus  wrote:
> 
> The BlobStore is being mentioned as the new advanced way of using storing 
> blobs in http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html 
> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html>.
> Unfortunately neither http://jackrabbit.apache.org/oak/docs/osgi_config.html 
> <http://jackrabbit.apache.org/oak/docs/osgi_config.html> nor 
> http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#SegmentNodeStore 
> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#SegmentNodeStore>
>  or 
> http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#DocumentNodeStore
>  
> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#DocumentNodeStore>
>  list that as an option. Also it is not mentioned as being supported by the 
> Blob Garbage Collection 
> (http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Blob_Garbage_Collection
>  
> <http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Blob_Garbage_Collection>).
> 
> So the question is: Is it safe to use the FileBlobStore instead of the 
> FileDataStore in production? When I tried 2 years ago I ran into 
> https://issues.apache.org/jira/browse/OAK-1842 
> <https://issues.apache.org/jira/browse/OAK-1842> which is now fixed. I am 
> wondering whether that option is recommended to use for a production setup or 
> whether that option is considered unstable (because it is also not mentioned 
> in 
> https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html 
> <https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html>)?
> 
> Thanks for any advice. 
> Konrad
> 
> BTW it would be great if the documentation pages listed above could be a 
> littlebit clearer in that regard.

Production usage (and documentation) of FileBlobStore?

[Konrad Windszus]

The BlobStore is being mentioned as the new advanced way of using storing blobs 
in http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html 
.
Unfortunately neither http://jackrabbit.apache.org/oak/docs/osgi_config.html 
 nor 
http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#SegmentNodeStore 
 
or 
http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#DocumentNodeStore 

 list that as an option. Also it is not mentioned as being supported by the 
Blob Garbage Collection 
(http://jackrabbit.apache.org/oak/docs/plugins/blobstore.html#Blob_Garbage_Collection
 
).

So the question is: Is it safe to use the FileBlobStore instead of the 
FileDataStore in production? When I tried 2 years ago I ran into 
https://issues.apache.org/jira/browse/OAK-1842 
 which is now fixed. I am 
wondering whether that option is recommended to use for a production setup or 
whether that option is considered unstable (because it is also not mentioned in 
https://docs.adobe.com/docs/en/aem/6-2/deploy/platform/data-store-config.html 
)?

Thanks for any advice. 
Konrad

BTW it would be great if the documentation pages listed above could be a 
littlebit clearer in that regard.