Hello Devs,
Currently xwiki-officeimporter contains logic for mainly two different
tasks:
1. Manage the back-end openoffice process (and provide document conversion
facilities).
2. Perform the actual transformation from office documents to wiki pages.
(depends on point 1)
xwiki-officeimporter
Hi Asiri,
Right now I don't see any use case for reusing an openoffice module
outside of the office importer/exporter.
My current view:
- we could extract this module but as a nested submodule of xwiki-
officeimporter (could be renamed xwiki-office and have 3 submodules:
On 12/19/2009 10:52 AM, Asiri Rathnayake wrote:
Hello Devs,
Currently xwiki-officeimporter contains logic for mainly two different
tasks:
1. Manage the back-end openoffice process (and provide document conversion
facilities).
2. Perform the actual transformation from office documents to
Hi,
Will this module be useful outside the import/export feature? Can you
think of any standalone usage?
Other than import / export features, No. What I had in mind is something
like what vincent suggested. I also have to agree that doing this kind of a
separation just for the sake of
Hi Devs,
I just realized that I've been having a velocity bridge class inside an
*.internal package for sometime.
I think this is wrong because velocity bridges are part of our public API
(?). Moving this bridge to a non-internal package would not harm because it
would not break any existing
Hi,
Same issue here, why would you need the exporter as a separate platform
module?
IMO, you should have a single platform module for the office
import/export functionality, and have the server management, importer
and exporter as nested modules.
This is what vincent has suggested (is it
6 matches
Mail list logo
