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.
Ate Douma wrote:
Carsten Ziegeler wrote:
Big +1 for using Confluence; we are using it for several projects (Felix,
Sling, Jackrabbit) already and it works
nicely.
If they have a CLA on file, and are contributing to the official project
documentation, they *ARE* Committers.
They just aren't coders, and don't have SVN access.
Well, that's not how I understand how it is described on the CWIKI page, or
even here:
http://www.apache.org/foundation/how-it-works.html. Although a committer must
have a CLA on file, can't a
"contributer" have a CLA on file too without being a committer?
Yes, that's how we do it in other projects. You need a CLA and then can contribute
to the docs without being a "svn
committer".
Cool, that's what I thought too.
Ate Douma wrote:
My proposal is simple: - switch to using this Confluence+cwiki solution
I assume you mean for the whole portals project. +1
Well, I indicated upfront to propose this (initially) for Jetspeed-2 only. But
of course, I'd like to see this to be
extended to the whole of Portals project too. See also my comments below.
- maintain separate Confluence spaces for release specific
documentation
for jetspeed-2, j2-admin and future products
Hmm, not sure if we need this. So this would also include to have a specific
space for Pluto, Bridges etc?
Yes, and even potentially, depending on the goals for each project, distinct
spaces per each (major) release. See for
example how Geronimo handles this: Main website space -
http://cwiki.apache.org/GMOxSITE/ Trunk development
space - http://cwiki.apache.org/GMOxDEV/ Geronimo v1.0 space -
http://cwiki.apache.org/GMOxDOC10/ Geronimo v.1.2
space - http://cwiki.apache.org/GMOxDOC12/ Geronimo v.2.0 space -
http://cwiki.apache.org/GMOxDOC12/ etc.
Now, if we are going to extend my proposal for the whole of Portals project (or
at least including the main site), we
might optimize this a bit. In my view, there is/should only be a need for one
primary (release independent) website
space. This space (PORTALS) can then contain all general information for both
the Portals project (like
http://portals.apache.org) as well as for the subprojects (Jetspeed, Pluto,
Bridges, etc.). Then, each sub project
can need additional release related spaces, like J2xDOC213, J2xDOC22,
PLUTOx115, PLUTOx20, BRIDGESx104.
Finally, we can simply switch to one Confluence space for the "public" wiki for
the whole Portals project too,
something like PORTALSxWIKI.
- integrate all the above in one new main cwiki based jetspeed-2
project
website
Can you elaborate a little bit on this one please?
The global PORTALS space should integrate all of the above spaces similar to
how other projects do this, as well as
additional resources like generated javadocs, reports etc. for which we still
can use maven but need to provide links
to from the Confluence space(s).
So, if you would want to expand this proposal to include Portals itself, Pluto,
Bridges, maybe even WSRP4J etc., +1
Ate
Carsten
