20 Mar
2015
20 Mar
'15
4:54 p.m.
Hi Vincent
Thanks for your answer. The celements team is indeed interested in
contributing more to the XWiki project. Therefore we would be willing to
develop a migration module the way you proposed. This would also enable
us to upgrade celements to a more recent XWiki version. If you agree, we
could start with a design document on http://design.xwiki.org.
On an somewhat unrelated note, is there a way to include hibernate
mappings in XWiki Extensions? I cannot find any mention of it in the
extension wiki
(http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Manager+Appl…).
Regards
Marc
synventis gmbh
On 20.02.2015 14:09, vincent(a)massol.net wrote:
Hi Marc,
On 18 Feb 2015 at 17:19:01, Marc Sladek
(marc.sladek@synventis.com(mailto:marc.sladek@synventis.com)) wrote:
Dear XWiki devs
Within the scope of our XWiki-based project called celements, we are
using
several so-called "modules", which
consist of JARs, web resources
(VM/CSS/JS files) and hibernate mappings. These modules extend the
functionality of the base application and can be optionally added if
required. We need to update and migrate these modules independently from
XWiki. Therefore we require to store individual migration version
numbers
in the database for each module.
XWiki's single implementation of
DataMigrationManager, HibernateDataMigrationManager, isn't intended to
store multiple version numbers with specific identifiers in the
database.
There also doesn't seem to be an evident hook
from XWiki to
seamlessly add
own implementations of the DataMigrationManager
to the application to
allow migration subsystems.
Considering the similarities of XWiki extensions to our modules, is
there
already a way that we have missed to achieve
independent migrations
of our
modules?
I recently introduced the xwiki-platform-instance module which creates
its own DB table to store the XWiki instance id. You can do something
similar for your “modules”, i.e. one table with each row containing a
module name + a module version.
Another option you have is to use the permanent directory and store
the versions in a file there (in a properties file for example to make
it easy to read/write).
About hooks, there’s an Application Started Event or a Database Ready
Event that you can use to perform your checks/migrations.
If not, are there any future plans from
XWiki's side to add this
functionality?
We’ve not seen the need so far, so there’s no future plan ATM.
Now, if you’re willing to work on this, I guess it could be possible
to refactor the XWiki Migration Manager into its own module in XWiki
and in addition, make it more generic so that it can support plugging
external migrations that would want to benefit from a store and from
hibernate/liquibase migrations.
It’s certainly not a priority for the xwiki dev team but if you were
willing to do the work, maybe it’s possible. Don’t know what others
think about this.
We’re always happy to get more contributions in general! It would be
great if the celements team
(http://www.celements.ch/Home?language=en) could contribute more stuff
on extensions.xwiki.org <http://extensions.xwiki.org> or participate
to XWiki’s dev in one way or another! :) (having some active committer
in the project would also allow you to advertise your company/project
on xwiki.org <http://xwiki.org>, see
http://dev.xwiki.org/xwiki/bin/view/Community/Governance).
Thanks
-Vincent
> Thanks in advance
>
> Marc Sladek
> synventis gmbh