Loading...

general@portals.apache.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [PROPOSAL] Move to confluence and cwiki for project website and documentation Carsten Ziegeler Tue Jul 08 11:11:38 2008

Hmm, I agree that this is a problem. In Felix we solve this (partially) by prefixing the page names with the sub projects. It works but calls for trouble over time.

I can only say that I really hate (perhaps hate is a little bit too strong) the current MoinMoin installation we have. If newer versions are better, I would be fine with that; but I doubt that this will be easy to be maintained by infra. On the other hand Confluence has a very strong support.

Now, we have two problems if I understand this correctly:
a) Possible page name clashes in the general content
This could be solved by prefixing; as this content is more of a static nature, we should come around this.

b) Nesting of spaces
I'm not quiet sure, but I think this can be easily done. If we export the general space to portals.a.o, the j2 space to portals.a.o/j2 etc. everything should work out of the box. Or do I oversee something here?

I think it's easier to go with the problems of a maintained software than trying to use something which is currently not installed. But I'm following majority here.

Carsten
Ate Douma wrote:
After doing some further research and actually playing around with a standalone installation of Confluence and the AutoExport plugin, I'm not really positive about this proposal anymore :(

Especially with regards to managing and integrating the confluence content for multiple Portals sub projects, I've noticed some very serious confluence limitations.
These limitations are quite known and much sought after to be solved, see:

  http://jira.atlassian.com/browse/CONF-2524
  http://jira.atlassian.com/browse/CONF-1095

The main limitation (in my view) is that confluence page titles need to be unique within one Space. Considering commonly expected page titles like Index, Documentation, Reports, etc. which each project would want or need to create, this is going to be a big problem trying to handle all that in one confluence Space (which was the idea for the standard/non-release related content). The only "solution" to that problem would be using some kind of ugly pre/postfixing page titles, like J2Index, PlutoIndex etc., ugh...

Currently the only real solution is to use separate confluence spaces for even the general content of each independent (sub) project, and not only just for their (major) release documentations. Now, considering we are also going to start with the new APA project, which (by intent) will be composed of multiple, independent, sub projects again, we're looking at quite a lot of confluence spaces for the Portals project only (easily growing to 10-20 or more).

I don't think that, from a managerial POV, this is going to be acceptable, neither for infra or ourselves.

Last but certainly not least, confluence (in contrast to many other wiki's, including MoinMoin) doesn't grog sub pages, folders or nested Spaces.

As the cwiki solution requires generating exported static html from Confluence for each Space to be merged into one coherent single Portals website / url space, this is going to be extremely difficult to do. In fact, I've got a feeling this might turn out to be even more difficult/buggy than trying to achieve this with a maven 2 site setup.

The biggest problem in my view with these issues is the fact that Confluence is a closed source solution with makes it impossible for us to assess the scope of these problems, the options available to workaround them, or even provide patches/fixes.

The handling of the above mentioned JIRA issues by Atlassian also doesn't make me optimistic these are going to be solved any time soon.

Why didn't I notice these problems before and don't other projects seem to have these issues? Probably because AFAIK none of the other projects have as much (independent) sub projects as we (are going to) have, so they only have to manage a handful of Spaces the most (Geronimo being exceptional with already 15+ spaces).

Unless anyone has some knowledge or ideas how these issues can be circumvented or tell me I have completely misunderstood all this, I'm going to change my opinion to -1 for this solution.

But...

This doesn't mean there isn't or might not be an alternative.

I decided to now properly check out the capabilities and features of MoinMoin as only other Wiki based solution available to us. And to my surprise, it seems to be capable of *much* more than what currently is used or provided by the installation on wiki.apache.org.

This is mostly caused by Apache still using a hacked/forked version 1.3.4 (released 3 years ago: where was Confluence at that time, feature wise?). The latest MoinMoin 1.6 definitely supports many (if not all or more) of the features I think why we were looking at Confluence for: - Easy editing, WYSIWYG, multiple (wiki) languages, custom client side editing support (e.g. editmoin)
- easy to use python macros and extendability, theming
- many (free/open-source) plugins/macros/actions available
- modular/pluggable authentication
- very flexible ACL configuration (users/groups, definition support)
- sub pages! (like: http://moinmo.in/HelpOnEditing/SubPages)
- sub pages can also inherit parent page ACL settings (something Confluence cannot either)
- custom themes, page templates
- etc.

Some relevant links worthwhile checking out:
  http://moinmo.in/
  http://moinmo.in/MoinMoinScreenShots
  http://moinmo.in/MoinMoinFeatures
  http://moinmo.in/HelpOnEditing/SubPages
  http://moinmo.in/HelpOnAccessControlLists
  http://moinmo.in/HelpOnAuthentication

I know, just a week ago I proposed the cwiki/confluence solution, which at least is (somewhat) supported by infrastructure, and the latest version of MoinMoin certainly (not) yet.

But in my current view, MoinMoin potentially can provide us with a really good solution. Its open source, fast, and would even allow *inline* editing (with proper authentication and ACL that is) of the website. No funky jumping-through-hoops kind of intermediate exporting, merging and additional url-rewriting needed!

Looking at the current state and maintenance of MoinMoin at Apache though, I'm doubtful if anyone at infrastructure is willing to move to the latest version *for* wiki.apache.org, which is one large wiki farm across Apache.

If there is enough interest for this though, maybe we can ask infra if we can get portals.apache.org hosted on a separate (latest) instance of MoinMoin. But as infrastructure already seems to be stressed quite a lot, that might be problematic too.

Anyway, I'd like to know if anyone else has experience with more recent MoinMoin installations and opinions about properly using MoinMoin (to the fullest) as alternative solution.




--
Carsten Ziegeler
[EMAIL PROTECTED]