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 
* 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-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)


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


devs mailing list

Reply via email to