You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Konrad Windszus <ko...@gmx.de> on 2019/08/26 12:00:16 UTC
FileVault: Require Java 8
Hi, currently FileVault is still supporting Java 7.
But with https://issues.apache.org/jira/browse/JCRVLT-344 <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
Re: FileVault: Require Java 8
Posted by Konrad Windszus <ko...@gmx.de>.
As long as it is not embedded that shouldn't be any problem.
But it is very hard to ensure backwards compatibility that way, because currently there is no IT testing FileVault with Java 7 and Jackrabbit 2.14.
Konrad
> On 5. Sep 2019, at 09:43, Julian Reschke <ju...@gmx.de> wrote:
>
> On 05.09.2019 03:18, Tobias Bocanegra 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.
>> ...
>
> Even if the JAR file for jackrabbit-api is compiled with Java 8?
>
> Best regards, Julian
Re: FileVault: Require Java 8
Posted by Julian Reschke <ju...@gmx.de>.
On 05.09.2019 03:18, Tobias Bocanegra 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.
> ...
Even if the JAR file for jackrabbit-api is compiled with Java 8?
Best regards, Julian
Re: FileVault: Require Java 8
Posted by Konrad Windszus <ko...@gmx.de>.
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 <tr...@adobe.com> 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 <ko...@gmx.de> 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 <tr...@adobe.com> 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 <ko...@gmx.de> 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
>>>>
>>>>
>>>
>>
>
Re: FileVault: Require Java 8
Posted by Tobias Bocanegra <tr...@adobe.com>.
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 <ko...@gmx.de> 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 <tr...@adobe.com> 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 <ko...@gmx.de> 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
>>>
>>>
>>
>
Re: FileVault: Require Java 8
Posted by Konrad Windszus <ko...@gmx.de>.
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 <tr...@adobe.com> 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 <ko...@gmx.de> 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
>>
>>
>
Re: FileVault: Require Java 8
Posted by Tobias Bocanegra <tr...@adobe.com>.
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 <ko...@gmx.de>> 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