Carsten Ziegeler wrote:
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.
Belief me, I'm not a fan of the current installation either.
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.
True, but the current MoinMoin is maintained/support too and I don't see that
going away any time soon.
The question is: when, how and by whom can our current version be upgraded?
And if that won't be possible any time soon, can we have a second/independent
installation (just for
portals.apache.org)?
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.
Yes, that can be done. But Felix and most other projects don't have full blown
sub projects to consider, each with
usually many similar topics to describe. With Portals, this is quite different.
We need to specify strict naming rules to keep us from ending up in a big mess.
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?
No, I agree that's the general idea.
But what I'm afraid of is that we are going to see an explosion of confluence
spaces:
1) site: general + pluto + bridges + apa (+apps) + j2 + j2admin + wsrp4j (all
in one space)
2) pluto v1.1.5 doc
3) pluto v2.0 doc
4) bridges v1.0.4 doc
5) j2 v2.1.3 doc
6) j2 v2.2 doc
7) j2-admin v2.2 doc
8) wsrp4j v1.0 doc
10) apa-<app1> v1.0 doc
11) apa-<app2> v1.0 doc
13) apa-<app3> v1.0 doc
Of course, the above set is just the beginning, with newer (major) releases
and/or new apa apps added, this set might
expand rapidly.
The nice thing of MoinMoin is that one doesn't have to concern itself with all these
"Spaces", unique page names etc,
nor merging separate "spaces" in one url space: everything can be managed
inline/online and in realtime with MoinMoin.
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.
Without some kind of infra support for a newer/newest MoinMoin, I agree this
isn't going to work out.
I'm just stating my preference for if and why I think it is a better
alternative, but only *if* it can be supported.
Confluence is "nice", but also a pain in some quite important area's.
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.
