Migration Framework Improvement

Development
,
#1

Ideally, By the end of August, The following features will be implemented:

  • A Property migrator that migrates XProperties inside old Objects to the new one.
  • A Script migrator that migrates old scripts while taking care of their hierarchy relationship in the script context
    [http://jira.xwiki.org/projects/MIGRATOR/issues/MIGRATOR-10?filter=allopenissues]
  • Create reusable mock migration script services that fulfill as many cases as we can think of, along with triggers that can manually start mock migrations

(The features that don’t have jira links will be added once they are opened.)

1 Like
#2

@caubin @lucaa, I will put this question here so that anyone who wants to catch up can see the summarized information. Do you still agree that for now, we can merge -api & -default module to reduce the complexity?

#3

Hi Eric,

It’s good on my side, thanks for bringing this topic on the forum. I’m still fine with merging the -api and -default modules as a start, and then go over the elements that you mentioned in your fist post.

Thanks,
Clément

#4

Hi Eric/Clement,

Could you explain more the rationale? It goes a bit counter to the general best practices we use. If it’s just about to reduce the complexity I don’t see why it’s complex to have more than 1 module. Why was there 2 modules from the beginning? Was that a mistake? Is the rationale just that it’s not needed to have 2 modules?

Note that you’ll need more than 1 module in total anyway (for the functional tests for example).

Also note that what you did in the PR/branch was not quite correct I think:

  • You broke EM upgrade AFAIR, since you didn’t use the EM alias feature and thus it won’t be possible to upgrade from older versions of this extension.
  • You kept an -api module which doesn’t make sense since it’s no longer an API
  • You had commented out code that should be removed
#5

a new pull request is open for the issue: https://jira.xwiki.org/browse/MIGRATOR-13

this issue aims to create a basic property migrator that by now supports two types of migration:

  1. when the resource property and the destination property are the same type
  2. when the type of the destination property is “String”