[xwiki-devs] [Proposal] Future of XAR Import/Export code
Hi devs, We are trying to reduce the size of oldcore (been working on it for years ;)). We currently have code for XAR import and export in several places in oldcore. I’d like to define the strategy that we’d like to follow in the future for moving this code out. Let’s see what we have and what it could become: * An existing ‘filter" module outside of oldcore to import/export XAR. * An action for exporting a XAR: ExportAction. Future: make it a new URL type with components as we’ve done for webjars * An action for importing a XAR: ImportAction. Future: make it a new URL type with components as we’ve done for webjars * A UI at the page level to export a page as a XAR. Future: add an UIXP in export_modal.vm and plugin the XAR option as an UIX * 2 Uis in the admin to import and export XARx. Future: convert those for ConfigurableClass. * A legacy “packaging” plugin with oldcode to import XARs. Future: retire it in xwiki-contrib and rewrite the Import/Export Admin UI to use the new XAR filter from the filter module. * Ancillary classes such as XARImport*/XARExport* events. So the question is where to put those? Proposal: xwiki-platform-xar ===================== I think what would make the most sense would be to continue the XAR module started by Thomas: xwiki-platform-xar. It would go like this: xwiki-platform-xar |_ xwiki-platform-xar-api (what’s currently in xwiki-platform-xar + Java code from oldcore defined above) |_ xwiki-platform-xar-ui (the ui part of the oldcore code above) |_ xwiki-platform-xar-filter (the move from xwiki-platform-filter-stream-xar) WDYT? The other option that I like less would be to group everything under the filter module but it doesn’t seem good. I’d prefer to keep this module generic as much as possible and have “business” modules using it (XAR import/export, Confluence import/export, MediaWiki,import/export, etc). Thanks -Vincent
+1 2016-09-15 9:38 GMT+02:00 Vincent Massol <[email protected]>:
Hi devs,
We are trying to reduce the size of oldcore (been working on it for years ;)). We currently have code for XAR import and export in several places in oldcore.
I’d like to define the strategy that we’d like to follow in the future for moving this code out.
Let’s see what we have and what it could become: * An existing ‘filter" module outside of oldcore to import/export XAR. * An action for exporting a XAR: ExportAction. Future: make it a new URL type with components as we’ve done for webjars * An action for importing a XAR: ImportAction. Future: make it a new URL type with components as we’ve done for webjars * A UI at the page level to export a page as a XAR. Future: add an UIXP in export_modal.vm and plugin the XAR option as an UIX * 2 Uis in the admin to import and export XARx. Future: convert those for ConfigurableClass. * A legacy “packaging” plugin with oldcode to import XARs. Future: retire it in xwiki-contrib and rewrite the Import/Export Admin UI to use the new XAR filter from the filter module. * Ancillary classes such as XARImport*/XARExport* events.
So the question is where to put those?
Proposal: xwiki-platform-xar =====================
I think what would make the most sense would be to continue the XAR module started by Thomas: xwiki-platform-xar.
It would go like this:
xwiki-platform-xar |_ xwiki-platform-xar-api (what’s currently in xwiki-platform-xar + Java code from oldcore defined above) |_ xwiki-platform-xar-ui (the ui part of the oldcore code above) |_ xwiki-platform-xar-filter (the move from xwiki-platform-filter-stream- xar)
WDYT?
The other option that I like less would be to group everything under the filter module but it doesn’t seem good. I’d prefer to keep this module generic as much as possible and have “business” modules using it (XAR import/export, Confluence import/export, MediaWiki,import/export, etc).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
+1 with one note On Thu, Sep 15, 2016 at 9:50 AM, Guillaume Delhumeau <[email protected]> wrote:
+1
2016-09-15 9:38 GMT+02:00 Vincent Massol <[email protected]>:
Hi devs,
We are trying to reduce the size of oldcore (been working on it for years ;)). We currently have code for XAR import and export in several places in oldcore.
I’d like to define the strategy that we’d like to follow in the future for moving this code out.
Let’s see what we have and what it could become: * An existing ‘filter" module outside of oldcore to import/export XAR. * An action for exporting a XAR: ExportAction. Future: make it a new URL type with components as we’ve done for webjars * An action for importing a XAR: ImportAction. Future: make it a new URL type with components as we’ve done for webjars * A UI at the page level to export a page as a XAR. Future: add an UIXP in export_modal.vm and plugin the XAR option as an UIX * 2 Uis in the admin to import and export XARx. Future: convert those for ConfigurableClass. * A legacy “packaging” plugin with oldcode to import XARs. Future: retire it in xwiki-contrib and rewrite the Import/Export Admin UI to use the new XAR filter from the filter module. * Ancillary classes such as XARImport*/XARExport* events.
So the question is where to put those?
Proposal: xwiki-platform-xar =====================
I think what would make the most sense would be to continue the XAR module started by Thomas: xwiki-platform-xar.
It would go like this:
xwiki-platform-xar |_ xwiki-platform-xar-api (what’s currently in xwiki-platform-xar + Java code from oldcore defined above)
Note: the module containing actual XAR format tools (i.e. the current xwiki-platform-xar module) should stay light on the dependencies and not depend on anything like oldcore so if you plan to move actions we will need two different modules.
|_ xwiki-platform-xar-ui (the ui part of the oldcore code above) |_ xwiki-platform-xar-filter (the move from xwiki-platform-filter-stream- xar)
WDYT?
The other option that I like less would be to group everything under the filter module but it doesn’t seem good. I’d prefer to keep this module generic as much as possible and have “business” modules using it (XAR import/export, Confluence import/export, MediaWiki,import/export, etc).
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 15 Sep 2016, at 10:11, Thomas Mortagne <[email protected]> wrote:
+1 with one note
On Thu, Sep 15, 2016 at 9:50 AM, Guillaume Delhumeau <[email protected]> wrote:
+1
2016-09-15 9:38 GMT+02:00 Vincent Massol <[email protected]>:
Hi devs,
We are trying to reduce the size of oldcore (been working on it for years ;)). We currently have code for XAR import and export in several places in oldcore.
I’d like to define the strategy that we’d like to follow in the future for moving this code out.
Let’s see what we have and what it could become: * An existing ‘filter" module outside of oldcore to import/export XAR. * An action for exporting a XAR: ExportAction. Future: make it a new URL type with components as we’ve done for webjars * An action for importing a XAR: ImportAction. Future: make it a new URL type with components as we’ve done for webjars * A UI at the page level to export a page as a XAR. Future: add an UIXP in export_modal.vm and plugin the XAR option as an UIX * 2 Uis in the admin to import and export XARx. Future: convert those for ConfigurableClass. * A legacy “packaging” plugin with oldcode to import XARs. Future: retire it in xwiki-contrib and rewrite the Import/Export Admin UI to use the new XAR filter from the filter module. * Ancillary classes such as XARImport*/XARExport* events.
So the question is where to put those?
Proposal: xwiki-platform-xar =====================
I think what would make the most sense would be to continue the XAR module started by Thomas: xwiki-platform-xar.
It would go like this:
xwiki-platform-xar |_ xwiki-platform-xar-api (what’s currently in xwiki-platform-xar + Java code from oldcore defined above)
Note: the module containing actual XAR format tools (i.e. the current xwiki-platform-xar module) should stay light on the dependencies and not depend on anything like oldcore so if you plan to move actions we will need two different modules.
Yes, we could call it xwiki-platform-xar-model Thanks -Vincent
|_ xwiki-platform-xar-ui (the ui part of the oldcore code above) |_ xwiki-platform-xar-filter (the move from xwiki-platform-filter-stream- xar)
WDYT?
The other option that I like less would be to group everything under the filter module but it doesn’t seem good. I’d prefer to keep this module generic as much as possible and have “business” modules using it (XAR import/export, Confluence import/export, MediaWiki,import/export, etc).
Thanks -Vincent
participants (3)
-
Guillaume Delhumeau -
Thomas Mortagne -
Vincent Massol