3 Oct
2011
3 Oct
'11
2 p.m.
Thinking about it, another option would be:
6) Disconnect just the problematic workspace-template module from the
platform, keeping the rest, and leave the importing of a customized XE xar
(workspace-template) the task of the admin that is installing workspaces.
Customized XE XARs can be published on extensions.xwiki.org and downloaded
from there manually. (quick to do)
If 2) is not an option, my +1 goes to 6).
Thanks,
Eduard
On Mon, Oct 3, 2011 at 2:41 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi devs,
The workspace module has a maven artefact (workspace-template) that
produces an enhanced (adds extra pages, set some properties, overrides some
pages, etc.) XE xar that is to be used by all the created workspaces. The
problem is that, being part of the platform, this creates a cyclic
dependency in maven thus breaking the build. Also, the 3.2RC1 release is
supposed to be today, so the matter is rather urgent.
To fix this, there might be a couple of solutions on which I`d like your
opinion/vote:
1) Rewrite the workspace-template module and, instead of using maven to
produce a customized XE xar, use velocity within the workspace application
to enhance a standard XE xar at runtime, when actually creating the
workspace. (needs some time)
2) Move the workspace-template module into the XEM build and bundle
workspace by default with XEM. (quick to do)
3) Move the workspace-template module into the XE build, even though
workspaces is not bundled by default with XE. (quick to do, but not
necessarily right)
4) Unlink the workspace module from the platform build, so that it is
skipped from the build and that it does not break it, but leave the hooks.
(quick to do, leaves way for further work)
5) Just revert everything related to workspaces from the platform and
possibly keep the existing work in a branch. (quick to do, but also removes
the hooks)
Here's my +1 for 2).
Thanks,
Eduard