You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Julian Reschke <ju...@gmx.de> on 2017/12/04 19:29:29 UTC
Oak in Jackrabbit components
I just noticed that jackrabbit-webdav (and other component) have a
dependency on OAK 1.0.12.
This seems to originate from
<https://issues.apache.org/jira/browse/JCR-3598> - "Oak in Jackrabbit
deployment packages" - which is still open today.
Can we either remove this, or clarify what Oak version should be used here?
Best regards, Julian
Re: Oak in Jackrabbit components
Posted by Marcel Reutegger <mr...@adobe.com>.
On 05/12/17 13:27, Julian Reschke wrote:
> How about starting with:
>
> - in trunk, remove the oak dependency
> - in trunk, move -webapp and -standalone into ./examples
> - in maintenance branches, update to latest OAK 1.0.*
+1
Regards
Marcel
Re: Oak in Jackrabbit components
Posted by Julian Reschke <ju...@gmx.de>.
On 2017-12-05 13:03, Marcel Reutegger wrote:
> Hi,
>
> On 05/12/17 12:50, Julian Reschke wrote:
>>> - Keep the duplicate modules, but remove the Oak dependency in
>>> Jackrabbit
>>
>> That would be my preference, for simplicity.
>
> OK, then let's do it this way.
>
>> Of course then the next question would be: just in trunk, or
>> everywhere?
>
> I don't have a strong preference, but I would probably only do it in
> trunk and only there move the two modules under examples. The Jackrabbit
> releases on the maintenance branch would still have the two modules. It
> may be a bit strange to suddenly remove them in patch releases. But then
> I'm also not really opposed to removing them, since I consider them
> examples.
How about starting with:
- in trunk, remove the oak dependency
- in trunk, move -webapp and -standalone into ./examples
- in maintenance branches, update to latest OAK 1.0.*
Best regards, Julian
Re: Oak in Jackrabbit components
Posted by Davide Giannella <da...@apache.org>.
On 05/12/2017 12:03, Marcel Reutegger wrote:
> I don't have a strong preference, but I would probably only do it in
> trunk and only there move the two modules under examples. The
> Jackrabbit releases on the maintenance branch would still have the two
> modules. It may be a bit strange to suddenly remove them in patch
> releases. But then I'm also not really opposed to removing them, since
> I consider them examples.
By the fact that we just release 2.16.0 and Oak is most probably the
main consumer I could agree on doing the same on the 2.16 branch only.
D.
Re: Oak in Jackrabbit components
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 05/12/17 12:50, Julian Reschke wrote:
>> - Keep the duplicate modules, but remove the Oak dependency in
>> Jackrabbit
>
> That would be my preference, for simplicity.
OK, then let's do it this way.
> Of course then the next question would be: just in trunk, or
> everywhere?
I don't have a strong preference, but I would probably only do it in
trunk and only there move the two modules under examples. The Jackrabbit
releases on the maintenance branch would still have the two modules. It
may be a bit strange to suddenly remove them in patch releases. But then
I'm also not really opposed to removing them, since I consider them
examples.
Regards
Marcel
Re: Oak in Jackrabbit components
Posted by Julian Reschke <ju...@gmx.de>.
On 2017-12-05 12:45, Marcel Reutegger wrote:
> Hi,
>
> On 05/12/17 11:47, Julian Reschke wrote:
>>> Btw, there is no oak-standalone. Do you mean oak-run? This one is
>>> different because it contains various tools that can indeed be used
>>> as is.
>>
>> oak-examples/standalone
>
> Oh, right. I was only looking at the top level modules. Thanks for the
> pointer. So, it looks like in Oak standalone and webapp are already
> considered examples.
>
> I guess this is yet another reason for moving also the Jackrabbit
> equivalents to examples and not release them anymore.
>
> But that doesn't answer your question why those modules are duplicated
> and what we should do with the dependencies from Jackrabbit to Oak.
>
> I see two options:
>
> - Keep the duplicate modules, but remove the Oak dependency in Jackrabbit
That would be my preference, for simplicity. Of course then the next
question would be: just in trunk, or everywhere?
> - Remove the modules in Jackrabbit and change the Oak variants to also
> work with Jackrabbit
Best regards, Julian
Re: Oak in Jackrabbit components
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 05/12/17 11:47, Julian Reschke wrote:
>> Btw, there is no oak-standalone. Do you mean oak-run? This one is
>> different because it contains various tools that can indeed be used as
>> is.
>
> oak-examples/standalone
Oh, right. I was only looking at the top level modules. Thanks for the
pointer. So, it looks like in Oak standalone and webapp are already
considered examples.
I guess this is yet another reason for moving also the Jackrabbit
equivalents to examples and not release them anymore.
But that doesn't answer your question why those modules are duplicated
and what we should do with the dependencies from Jackrabbit to Oak.
I see two options:
- Keep the duplicate modules, but remove the Oak dependency in Jackrabbit
- Remove the modules in Jackrabbit and change the Oak variants to also
work with Jackrabbit
Regards
Marcel
Re: Oak in Jackrabbit components
Posted by Julian Reschke <ju...@gmx.de>.
On 2017-12-05 11:35, Marcel Reutegger wrote:
> Hi,
>
> On 05/12/17 09:51, Julian Reschke wrote:
>>>> This seems to originate from
>>>> <https://issues.apache.org/jira/browse/JCR-3598> - "Oak in
>>>> Jackrabbit deployment packages" - which is still open today.
>>>>
>>>> Can we either remove this, or clarify what Oak version should be
>>>> used here?
>>>
>>> I would rather not remove this, but update to the most recent stable
>>> version.
>>
>> Per branch, or globally? So would Jackrabbit 2.12 use Oak 1.6.*, or
>> something from the "matching" Oak branch?
>
> I don't think we can do this globally. If these components are in use,
> even though I doubt it, user may be forced to upgrade the repository
> between patch releases. I would keep the branches on the 1.0.x releases
> and update the dependency to the most recent stable 1.0.x. For trunk, I
> would update to the most recent 1.6.x.
OK. FWIW, I just tried an upgrade to 1.6 and it fails due to changes in
the oak-upgrade API (which is in use for some IT tests).
>>> I'm still in favor of this replacement, but it probably means
>>> Jackrabbit components that bundle other components would have to go
>>> on their own release schedule.
>>
>> Understood, but that's additional work, too.
>>
>> FWIW, we already do have oak-standalone etc, right? Why duplicate this?
>
> Good question. The more I think about those components, the more I
> consider them samples and not components the Jackrabbit project should
> deliver/release as binaries.
>
> I don't think you would ever deploy jackrabbit-webapp as is. In my view,
> this is a sample and should be released with sources only (if at all).
> The same applies to jackrabbit-standalone, which bundles the
> jackrabbit-webapp.
+1
> Btw, there is no oak-standalone. Do you mean oak-run? This one is
> different because it contains various tools that can indeed be used as is.
oak-examples/standalone
Best regards, Julian
Re: Oak in Jackrabbit components
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 05/12/17 09:51, Julian Reschke wrote:
>>> This seems to originate from
>>> <https://issues.apache.org/jira/browse/JCR-3598> - "Oak in Jackrabbit
>>> deployment packages" - which is still open today.
>>>
>>> Can we either remove this, or clarify what Oak version should be used
>>> here?
>>
>> I would rather not remove this, but update to the most recent stable
>> version.
>
> Per branch, or globally? So would Jackrabbit 2.12 use Oak 1.6.*, or
> something from the "matching" Oak branch?
I don't think we can do this globally. If these components are in use,
even though I doubt it, user may be forced to upgrade the repository
between patch releases. I would keep the branches on the 1.0.x releases
and update the dependency to the most recent stable 1.0.x. For trunk, I
would update to the most recent 1.6.x.
>> I'm still in favor of this replacement, but it probably means
>> Jackrabbit components that bundle other components would have to go on
>> their own release schedule.
>
> Understood, but that's additional work, too.
>
> FWIW, we already do have oak-standalone etc, right? Why duplicate this?
Good question. The more I think about those components, the more I
consider them samples and not components the Jackrabbit project should
deliver/release as binaries.
I don't think you would ever deploy jackrabbit-webapp as is. In my view,
this is a sample and should be released with sources only (if at all).
The same applies to jackrabbit-standalone, which bundles the
jackrabbit-webapp.
Btw, there is no oak-standalone. Do you mean oak-run? This one is
different because it contains various tools that can indeed be used as is.
Regards
Marcel
Re: Oak in Jackrabbit components
Posted by Julian Reschke <ju...@gmx.de>.
On 2017-12-05 08:57, Marcel Reutegger wrote:
> Hi,
>
> On 04/12/17 20:29, Julian Reschke wrote:
>> I just noticed that jackrabbit-webdav (and other component) have a
>> dependency on OAK 1.0.12.
>
> you probably mean jackrabbit-webapp. AFAICS the webdav component does
> not have a dependency on Oak.
Right. The other one is -standalone (transitive).
>> This seems to originate from
>> <https://issues.apache.org/jira/browse/JCR-3598> - "Oak in Jackrabbit
>> deployment packages" - which is still open today.
>>
>> Can we either remove this, or clarify what Oak version should be used
>> here?
>
> I would rather not remove this, but update to the most recent stable
> version.
Per branch, or globally? So would Jackrabbit 2.12 use Oak 1.6.*, or
something from the "matching" Oak branch?
> Active development on the repository implementation happens primarily in
> Oak, while the 'classic' Jackrabbit implementation is pretty much in
> maintenance mode. I think the original idea was to replace the classic
> implementation with Oak at some point, but the effort stopped half way.
Right.
> I'm still in favor of this replacement, but it probably means Jackrabbit
> components that bundle other components would have to go on their own
> release schedule.
Understood, but that's additional work, too.
FWIW, we already do have oak-standalone etc, right? Why duplicate this?
Best regards, Julian
Re: Oak in Jackrabbit components
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
On 04/12/17 20:29, Julian Reschke wrote:
> I just noticed that jackrabbit-webdav (and other component) have a
> dependency on OAK 1.0.12.
you probably mean jackrabbit-webapp. AFAICS the webdav component does
not have a dependency on Oak.
> This seems to originate from
> <https://issues.apache.org/jira/browse/JCR-3598> - "Oak in Jackrabbit
> deployment packages" - which is still open today.
>
> Can we either remove this, or clarify what Oak version should be used here?
I would rather not remove this, but update to the most recent stable
version.
Active development on the repository implementation happens primarily in
Oak, while the 'classic' Jackrabbit implementation is pretty much in
maintenance mode. I think the original idea was to replace the classic
implementation with Oak at some point, but the effort stopped half way.
I'm still in favor of this replacement, but it probably means Jackrabbit
components that bundle other components would have to go on their own
release schedule.
Regards
Marcel