Always provide XWiki data migrations in internal package

Development
#1

Hi everyone,

it seems that historically we always provided hibernate data migration in public API package of XWiki. First in old-core: xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/store/migration at master · xwiki/xwiki-platform · GitHub but then also in other modules such as notifications: xwiki-platform/xwiki-platform-core/xwiki-platform-notifications/xwiki-platform-notifications-filters/xwiki-platform-notifications-filters-default/src/main/java/org/xwiki/notifications/filters/migration at master · xwiki/xwiki-platform · GitHub

IMO this is a bad practice as those are never meant to be reused, and per our best practice we’re supposed to mark them unstable which doesn’t make any sense for such components. @mleduc recently starting putting old core migrations in an internal package: xwiki-platform/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/org/xwiki/internal/migration at master · xwiki/xwiki-platform · GitHub which is clearly better.

So the proposal here is that we ensure in the future to always put those data migration components in internal package. I’m not sure we really need to write it down in best practices, as it should be common sense that it’s not API. I just wanted to write it down so we pay attention to not grouped those classes with the old ones in the future.

Thanks

#2

+1 since this is just logical as you say. I also don’t see a need to document it since we already have https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/JavaCodeStyle/#HPackagenames

Why not also move existing migrations to the internal packages with revapi exclusions explaining why (since it’s not meant to be reused, I doubt it would cause problems)?

Thx

#3

+1 thanks
+1 to move all existing migrations to internal as well

#4

+1 to put past and future hibernate migrations in an internal package

#5

+1