SLING-13127: Remove obsolete ImportOptions.setPatchKeepInRepo call

[bkkothari2255]

Issue: SLING-13127

In Apache Jackrabbit FileVault version 4.2.0, the ability to patch files in the filesystem was completely removed as part of JCRVLT-825.

Because the setPatchKeepInRepo(boolean) method no longer exists in the newer FileVault API, leaving this method call in Sling will break the build (Method Not Found) when Sling attempts to upgrade its FileVault dependency.

Removing this now removes technical debt for a clean FileVault upgrade.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[joerghoh]

@kwin Is there a chance to enforce a hard dependency to at least Filevault 4.2.0, which has the Patch option removed? Because otherwise there is still the option to run this code with a filevault older than 4.2.0, and I would consider that as a security risk.

(Because if there is no chance to do that, I would close this ticket and not implement it.)

[bkkothari2255]

@kwin Is there a chance to enforce a hard dependency to at least Filevault 4.2.0, which has the Patch option removed? Because otherwise there is still the option to run this code with a filevault older than 4.2.0, and I would consider that as a security risk.

(Because if there is no chance to do that, I would close this ticket and not implement it.)

@joerghoh @kwin That makes total sense regarding the security risk on older FileVault versions.

If you both agree it's the right path forward, I can bump the org.apache.jackrabbit.vault dependency version to 4.2.0 (or higher) in the pom.xml as part of this PR. The maven-bundle-plugin should then automatically generate the strict Import-Package range to enforce the hard dependency.

Just let me know if you would like me to add that

[joerghoh]

hi @bkkothari2255 I doubt that it's that easy, unless filevault 4.2.0 added some package dependency updates, which cannot be fulfilled by an 4.1.4 (the previous version).

apache/jackrabbit-filevault@jackrabbit-filevault-4.1.4...jackrabbit-filevault-4.2.0 shows for the package-info.java files only a change in formatting, not in any version number.

For that just updating the filevault-core dependency to 4.2.0 is not good enough.

[bkkothari2255]

hi @bkkothari2255 I doubt that it's that easy, unless filevault 4.2.0 added some package dependency updates, which cannot be fulfilled by an 4.1.4 (the previous version).

apache/jackrabbit-filevault@jackrabbit-filevault-4.1.4...jackrabbit-filevault-4.2.0 shows for the package-info.java files only a change in formatting, not in any version number.

For that just updating the filevault-core dependency to 4.2.0 is not good enough.

@joerghoh Great catch! I checked the source and you're right—the package version remained 2.16.0 in FileVault 4.2.0 despite the breaking API change. Because of this, standard OSGi won't generate the strict Import-Package we need.

@kwin Since we can't rely on the package version to enforce the secure engine, should we use a strict Require-Bundle as a workaround here, or just hold this PR until FileVault releases a corrected package version?