XWiki 1.0: Extensible Java-based wiki/application platform
Next generation of wikis have been established with products like Confluence, Jotspot (bought by Google), XWiki, projectforum et al.
InfoQ spoke to Vincent Massol - one of core committers of XWiki - regarding XWiki's vision, its platform-specific features, competition it faces, and support that it seeks:
When you download XWiki, you can build on top of the XWiki platform (as opposed to most wikis out there where you get a fixed wiki when you download the product).
Move to a component oriented architecture so that it's easier to reuse all the building bricks for creating collaborative applications and for swapping in other implementations for components.
XWiki is doing CMS from a direction different from that of "proper" CMS tools. The way we view it is that people like to use a wiki for its unstructured data and the ability to easily add information without bothering too much about categorizing it. By opposition CMS tools usually require that you have a clear vision of what you want from the onset, and accordingly create structure for holding that data. Both types of tools are needed as complementary but XWiki offers a tool which you can start using as a standard wiki and when some of your data need some structure, XWiki can accomodate it and you're not forced to buy a separate application that has no interaction with the wiki.XWiki developers can take advantage of scripting languages Velocity and Groovy. XWiki's scripting feature and its data model allow development of web applications at various levels. As a Java developer, one may also extend XWiki by developing XWiki Java plugin classes. As of this writing, the XWiki team is also working on portlet integration to install XWiki as a JSR 168 Portlet in any Portal.
The main differentiators with products like JotSpot are probably that XWiki is Open Source and targeted at the Enterprise market. The fact that Google bought Jotspot is good news for XWiki as it proves there's interest in that space.Support:
There are currently about 8-9 active committers with many contributors answering to questions, sending patches and suggesting improvements on XWiki lists. But, XWiki team is looking for more committers and also contributors who can contribute script snippets to put in XWiki pages, macros, plugins and applications. We need more skins coming from the community.Since 2005, XWiki has received support from Google through the Summer of Code program.
How would you compare it to Confluence?
I like the ability to script and call out from the pages using Velocity, but can you restrict that separate from editing rights?
How does XWiki compare to TWiki?
I have tried to compare them using www.wikimatrix.org/compare/TWiki+Confluence+Soc... and they look very similar, but TWiki's plugin list is overwhelming and seems to get deployed a lot (many success stories).
Which project has the most momentum? Google support probably matters some?
have a clear vision of what you want from the onset, and accordingly create structure for holding that dataand it may take some time for you to come up with a good/natural structure for your data, so
when some of your data need some structure, XWiki can accomodate itCool! But now it's absolutely right time to ask: Is there such thing as "Information refactoring" (something that would be similar to "code refactoring") - a set of well-defined patterns to perform a common operations to change the way data/information is structured? Would it be amazing to have such tool? :)
Re: Looks good...
The way it works is that the XWiki API is divided into 2: standard API that anyone having edit rights can call and more dangerous APIs for which you need to have programming rights. As you guessed, this is a right separate from the edit rights. Admins have it and it's possible to give to certain users. Programming rights is always required for writing Groovy scripts.
* For velocity: you can call a subset of the api with edit rights, you need programming rights for more "dangerous" APIs
* For Groovy: you always needs programming rights
Re: How does XWiki compare to TWiki?
There was a recent thread on comparing XWiki with TWiki on the XWiki mailing list:
Not sure what you mean by google support but we currently have some Google Summer of Code project and one of them is about Google Docs integration. See www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ for a list of the 7 GSOC project underway.
Hope it helps,
Re: Looks good...
Re confluence, I think it can be summarized as follows:
- Confluence provides a single wiki. This wiki is very nice: nice features, nice UI, nice L&F. Perfect for getting started quickly if your interest is in "standard" wiki (i.e. collaborative editing of content which I call "first generation wiki")
- XWiki provides a platform for creating collaborative applications ("second generation wiki"), the wiki being one such application. XWiki distributes a default wiki. To make a comparison this exactly like Eclipse. Eclipse is a platform for developing applications. The IDE (Eclipse JDT) is an example of such an application and was initially considered a demo of what could be done with Eclipse. Our default wiki is the same. It's a demo. However, exactly like Eclipse JDT has become a first class IDE, we've been working on transforming our default wiki into a first class wiki. We believe we've now reached a good state with XWiki 1.0. The focus of XWiki 1.1 is to continue on that path.
To summarize even more:
- Confluence: very good first generation wiki
- XWiki: very customizable, more flexibility, platform
With XWiki, in addition to being a standard wiki, it's very easy to develop web sites (having a public face and an internal more wiki like face) and to use it as a lightweight CMS too.
I hope this is a fair comparison :)
We do have a set of tools to help with "Information Refactoring":
- strong search engine, including ability to search in Objects
- renaming of pages including renaming of backlinks
- more important: strong API to manipulate documents and their contents. This API can be used to create new documents, create attachments, find links in pages, move content around, etc.
Re: How does XWiki compare to TWiki?
Has anybody got any experience to tell the two apart?
I like Confluence a lot and use it on a regular basis, it's a great wiki, but... it's just a wiki. You can obviously write nice plugins for it, but in the end, you can't build full-blown applications on top of it. On the other hand, XWiki is more than just a wiki, as it's a real application platform on top of which you can write apps.
A while back, I needed a wiki with some advanced data structures and a little logic for automatically organizing content, metadata, documents, and XWiki was clearly the sole platform that would let me create this mixed Wiki / CRUD application I had to write. I just needed a few days to familiarize myself with the underlying API, and to get up to speed to write this application.
I've had a great experience using this technology, and it makes sense to call it a second generation wiki engine, and I even prefer calling it an application platform as it's so easy to create mixed document/CRUD-driven applications on top of it.
Congratulations to the XWiki team for bringing such an advanced product!
Re: Looks good...
I haven't really used XWiki apart from taking a brief look at it and playing around for 5 minutes. Therefore I can't give a good comparison between the two products. However looking at the feature list of XWiki I can't figure out why Confluence is labeled as a "first generation wiki" and XWiki as a "second generation wiki".
The fact that you can use velocity and other script languages in the page directly is pretty nice, but probably only useful for developers. I found that many users are already challenged using simple macros in the page. In most cases this is because they lack the technical background and are still used to write in Word. However, in Confluence you can achieve something similar with User Macros allowing you to access java objects via Velocity.
Confluence is very flexible and can be heavily customized if you know Java and Velocity. The number of Plugins available for Confluence grows every week and ranges from simple content macros to completely new components.
Re: Looks good...
... Then it means xwiki.org doesn't do a good job of showing the applications you can build on top of the XWiki platform. I'm going to work on improving that in the coming weeks. Actually xwiki.org itself is using XWiki and is made of about 15 small applications. For example the References space is such an application (www.xwiki.org/xwiki/bin/view/References/). You can create references, search for them, edit them, and display them in a table as it's down in the space home page. This is a good example of a simple application.
But to give you a better visual idea of what can be achieved with a little more work, check out the XWiki Watch screenshots at www.xwiki.com/xwiki/bin/view/Solutions/XWikiWatch. XWiki Watch is a social/collaborative feed reader built 100% on the XWiki platform.
Obviously we don't expect casual users of the wiki to be developing such applications and this XWiki Watch example is extreme. However small applications like the References page I mentioned above are easily done by power users (those admins/champions/experienced users setting up the wiki for others to use) and you'd be surprised by what non developers can achieve (actually this References applications has been developed inside the wiki by a non developer who has never coded anything before ;)).