Hi, With https://github.com/apache/jackrabbit-filevault/pull/67 <https://github.com/apache/jackrabbit-filevault/pull/67> I upgraded the Oak dependency to 1.18 (from 1.16) for FileVault 3.4.x. With which AEM version should FileVault be compatible? AEM 6.4 comes with Oak 1.8.13 and AEM 6.5 with Oak 1.10. So both ship with older versions of Oak than FileVault depends on. Is that a problem from your PoV?
Doesn't it rather make sense to pin the Oak and Jackrabbit versions to the oldest version we want to be compatible with? Thanks in advance for any input, Konrad > On 5. Sep 2019, at 03:18, Tobias Bocanegra <[email protected]> wrote: > > Hi, > > ok. So from the jackrabbit / oak side we have: > > - Jackrabbit 2.18 - recommended version for Java 8 and newer > - Jackrabbit 2.16 - Java 8 and newer > - Jackrabbit 2.14 - recommended version for Java 7 - “end of life” planned > for Spring 2022 > > - Apache Jackrabbit Oak 1.16.0 (Java 8 and later) > - Apache Jackrabbit Oak 1.10.x (Java 8 and later) > - Apache Jackrabbit Oak 1.8.x (Java 8 and later) > - Apache Jackrabbit Oak 1.6.x (Java 7 and later) > > The relevant part for the vault-core osgi bundle is the dependency on the > jackrabbit APIs. It has no direct bundle dependency to > Oak. Also, it doesn't embed any other bundles, so as long as the APIs stay > Java version independent, it should all work. > > As for the CLI, we ignore the java7 compatibility and just include the > respective jackrabbit components that are needed (but again, no oak needed). > > So the only things I'm concerned with are actuall API changes in the > Jackrabbit API that are relevant for FileVault. > For example fixes in Filevault that use new features in > org.apache.jackrabbit.api.security.* that would force a AEM 6.3/Java7 > customer to use Jackrabbit 2.18. So far we were lucky and didn't use any new > Jackrabbit API for a long time I guess :-) > > > Anyways.... > I would keep 3.2.8 as the current 3.2.x release, create a 3.2 branch and hope > for the best :-) > And then start with 3.4 (Java 8, Jackrabbit 2.18, Oak 1.16) > > WDYT? > Regards, Toby > > >> On 3 Sep 2019, at 23:27, Konrad Windszus <[email protected]> wrote: >> >> I am a bit confused, >> Jackrabbit 2.16 requires Java 8 already and was already required with >> filevault 3.2.8 >> (https://github.com/apache/jackrabbit-filevault/blob/5104a49b4b0fcd25bfbcc202734cca490e55765d/parent/pom.xml#L43) >> Oak 1.6 on the other hand still supports Java 7 (it depends on Jackrabbit >> 2.14 -> >> https://github.com/apache/jackrabbit-oak/blob/024278e1e33935bb30729a36252a1c93cc0e0d18/oak-parent/pom.xml#L45) >> >> So why is the combination of Oak 1.6 / Jackrabbit 2.16 necessary? I would >> understand Oak 1.6 / Jackrabbit 2.14 (AEM 6.3, still supports Java 7). >> What should we now target for the next 3.x release? >> >> Thanks, >> Konrad >> >>> On 26. Aug 2019, at 19:54, Tobias Bocanegra <[email protected]> wrote: >>> >>> Hi, >>> >>> The problem is, that we need oak 1.6 / jackrabbit 2.16 compatible version >>> of filevault. I think that >>> https://issues.apache.org/jira/browse/JCRVLT-340 might already changed >>> that. If so, we need to update >>> The major version and jump to 4.0.0, if filevault no longer works with oak >>> 1.16. >>> And then we also need to start a dedicated 3.x branch for back ports. >>> >>> Regards, Toby >>> >>> >>>> On 26 Aug 2019, at 05:00, Konrad Windszus <[email protected]> wrote: >>>> >>>> Hi, currently FileVault is still supporting Java 7. >>>> But with https://issues.apache.org/jira/browse/JCRVLT-344 we implicitly >>>> require Java 8 (due to the dependency towards Oak 1.16 and Jackrabbit >>>> 2.18). >>>> Is it fine if with the next release version (3.2.10) we require Java 8? Or >>>> should we rather increase the second digit, i.e. release 3.4.0? >>>> >>>> Is Filevault using the same Odd/Even release policy as Jackrabbit/Oak? >>>> >>>> In any case I would strongly recommend to upgrade then also the FileVault >>>> Maven Plugin to Java 8. >>>> WDYT? >>>> Konrad >>>> >>>> >>> >> >
