18 Feb
2015
18 Feb
'15
5:18 p.m.
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? If not, are there any future plans from XWiki's side to add this
functionality?
Thanks in advance
Marc Sladek
synventis gmbh
20 Feb
20 Feb
2:09 p.m.
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 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, see http://dev.xwiki.org/xwiki/bin/view/Community/Governance).
Thanks
-Vincent
Thanks in advance
Marc Sladek
synventis gmbh
20 Mar
20 Mar
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 
23 Mar
23 Mar
3:16 a.m.
There is, take a look at what's happening here:
https://github.com/phenotips/phenotips/blob/master/components/patient-data-…
This registers a class as a supported entity type, where the class uses
annotations to define the mapping. I'd recommend using annotations as
well, unless you prefer XML mapping files, in which case you can change
addAnnotatedClass with addFile(path to mapping file).
I think this only works after the wiki is restarted, since an extension
installed while the wiki is running won't receive the
ApplicationStartedEvent.
On 03/20/2015 11:54 AM, Marc Sladek wrote:
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:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi Marc,
On 18 Feb 2015 at 17:19:01, Marc Sladek
(marc.sladek@synventis.com(mailto:marc.sladek@synventis.com)) wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
3561
days inactive
3594
days old
3 comments
3 participants
participants (3)
-
Marc Sladek -
Sergiu Dumitriu -
vincent＠massol.net