Hi Jukka,
I want to start working on OAK-1222 (migrating group memberships). Is
there already code and/or test cases that show how migration would
work?
are there already extension points for migrators?
regards, toby
On Wed, Oct 16, 2013 at 7:26 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Tue, Nov 26, 2013 at 4:55 AM, Tobias Bocanegra tri...@apache.org wrote:
I want to start working on OAK-1222 (migrating group memberships). Is
there already code and/or test cases that show how migration would
work?
The relevant code and test cases are in oak-upgrade. See also the (so
Hi,
On Fri, Oct 11, 2013 at 4:28 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
...I've been thinking about the upgrade/migration code (oak-upgrade,
OAK-458) over the past few days, and trying to figure out how we could
achieve that without having to keep the full Jackrabbit 2.x codebase
as
Hi
I see the problem and I agree that this in fact *is* a problem.
But I still don't agree with an integrated, transparent solution to this
upgrade problem. And I never will -- such application bloat and even code
duplication along with testing and maintenance etc. requirements just sound
Hi,
On Mon, Oct 14, 2013 at 4:38 AM, Felix Meschberger fmesc...@adobe.com wrote:
IMNSHO migration of Jackrabbit 2 based repositories to Oak is a one-shot
problem:
you apply this once to a repository and be done. So why load the application
with
a host of unneeded pieces ?
I'd like to make
Hi
Thanks for the clarifications. Yet, they more confirm my first impression than
they resolve the concerns.
Particularly your timing and smoothness assumptions. Migrating JR2 to Oak is
much more complex than migrating from one version of JR2 to the next. I would
even assume it is way more
Hi,
On Mon, Oct 14, 2013 at 4:27 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
Would this be a problem is there was a way for this additional
dependency to go away after startup, once the migration is done?
Yes, all the required code would go the oak-upgrade bundle that can be
dropped
Hi,
On Mon, Oct 14, 2013 at 9:09 AM, Felix Meschberger fmesc...@adobe.com wrote:
Thanks for the clarifications. Yet, they more confirm my first impression
than they resolve the concerns.
Particularly your timing and smoothness assumptions. Migrating JR2 to Oak is
much more complex
than
Hi,
I second Felix' comments and prefer a standalone upgrade tool. this does not
mean that an upgrade is always a manual step. the embedding application (e.g.
Sling) can still contain the tool and auto-upgrade if desired.
I even think that a migration could be done purely on the JCR level, for
Hi Jukka,
I think the situation is slightly different between OAK-458 and OAK-805
(although I come to roughly the same conclusion in both cases)
OAK-805: JR users that cannot upgrade their existing data store will be stuck
eternally after a migration (I think it is fair to assume and a
Hi,
I've been thinking about the upgrade/migration code (oak-upgrade,
OAK-458) over the past few days, and trying to figure out how we could
achieve that without having to keep the full Jackrabbit 2.x codebase
as dependency. The same question comes up for the support for
Jackrabbit 2.x datastores
11 matches
Mail list logo
