[xwiki-devs] [VOTE] Fixing cyclic dependency introduced by the workspace module
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
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 <[email protected]> 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
On Mon, Oct 3, 2011 at 2:00 PM, Eduard Moraru <[email protected]> wrote:
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).
+1 for 6)
Thanks, Eduard
On Mon, Oct 3, 2011 at 2:41 PM, Eduard Moraru <[email protected]> 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)
I don't understand exactly what it mean, if it's just moving the XE dependency from maven to velocity then -1
2) Move the workspace-template module into the XEM build and bundle workspace by default with XEM. (quick to do)
+0
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)
-1, it's a multiwiki related thing it should not be bundled with XE for the same reason we don't bundle wiki manager (or then we bundle both in XE).
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)
-0
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)
+0
Here's my +1 for 2).
Thanks, Eduard
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 10/03/2011 08:00 AM, Eduard Moraru wrote:
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)
+0.5
If 2) is not an option, my +1 goes to 6).
Thanks, Eduard
On Mon, Oct 3, 2011 at 2:41 PM, Eduard Moraru<[email protected]> 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)
-1
2) Move the workspace-template module into the XEM build and bundle workspace by default with XEM. (quick to do)
+1 I wouldn't bundle it by default, I'd just make it a different module built alongside the current XEM template, as an alternative.
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)
-1
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)
+0.5
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)
+0.5
Here's my +1 for 2).
Thanks, Eduard
-- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (3)
-
Eduard Moraru -
Sergiu Dumitriu -
Thomas Mortagne