Re: [xwiki-devs] Migration Manager Subsystems

2015-03-22 Thread Sergiu Dumitriu
There is, take a look at what's happening here:

https://github.com/phenotips/phenotips/blob/master/components/patient-data-sharing/secure-storage/src/main/java/org/phenotips/data/securestorage/internal/SecureStorageRegistrationHandler.java

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+Application).
 
 
 Regards
 
 Marc
 synventis gmbh
 
 On 20.02.2015 14:09, vinc...@massol.net wrote:
 Hi Marc,

 On 18 Feb 2015 at 17:19:01, Marc Sladek
 (marc.sla...@synventis.com(mailto:marc.sla...@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
 
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs


-- 
Sergiu Dumitriu
http://purl.org/net/sergiu/
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] Migration Manager Subsystems

2015-03-20 Thread Marc Sladek

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+Application).


Regards

Marc
synventis gmbh

On 20.02.2015 14:09, vinc...@massol.net wrote:

Hi Marc,

On 18 Feb 2015 at 17:19:01, Marc Sladek 
(marc.sla...@synventis.com(mailto:marc.sla...@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


___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


Re: [xwiki-devs] Migration Manager Subsystems

2015-02-20 Thread vinc...@massol.net
Hi Marc,

On 18 Feb 2015 at 17:19:01, Marc Sladek 
(marc.sla...@synventis.com(mailto:marc.sla...@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
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


[xwiki-devs] Migration Manager Subsystems

2015-02-18 Thread Marc Sladek
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
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs