Vincent wrote: > You seem to be knowing Confluence which is great, since it’s been more than > 10 years that I haven’t used it myself.
It's been a few years for me also, but I suspect many of the good features present then are still the most noticeable. > Indeed, I don’t know why there’s this "Ticket plugin” mentioned. I’ll check > with Caty. XWiki certainly doesn’t have a full ticket extension right now > AFAIK. The closest I can think of is the Task Application: > http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Appli > cation Yes, I looked into this but it felt like a proof of principle rather than an actively used and maintained product. I ended up going with the Redmine plugin instead for a while, but it wasn't anything near Jira. > > The extensions in XWiki really vary in quality, whereas Confluence has a lot > of very polished plugins. That's at least been my experience, and I think > there's a need to distinguish between high-quality maintained extensions vs. > the more hacky ones. > > Definitely. I’ve also discussed this with others and it’s time that we start > curating extensions and introduce some “Editor Picks” or “Recommended” > extensions. I’ll start this in another thread real soon. I think this is a smart move. A decent set of flagship plugins could really set the standard for others. Also, if you're competing with Confluence, it's important to keep in mind that it's not just a wiki. The appeal of Confluence is that it's a great wiki with excellent integration with Atlassian's other (also great) products like Jira and source code repositories. To appeal to the same audience you really need to have a strong ecosystem built around the XWiki platform. > > > The lack of a markup editor in Confluence is a big difference. Might be > worth illustrating further. > > Agreed. Maybe the polyglotism too (ability to use various markup syntaxes). Maybe. Sometimes too much choice can be a bad thing. A single really good markup language is better that multiple similar ones. But being able to port easily from other systems with different markups is certainly a good thing. On several occasions I've found myself investing time writing content in one system, and then years later being unable to move to better platforms because the markup languages are incompatible and not having the time to port things over manually. > > > I think the page hierarchy model is rather difference. Confluence makes > chaining of child pages very easy, and access restrictions to child pages is > simple to manage. XWiki was a bit clunky by comparison, but that was for 7.1 > and maybe the addition of sub-spaces in more recent versions makes this > easier to manage. > > Could you explain why it’s simpler with Confluence by comparison with, say, > XWiki 7.4.3? I think this now at least as easy if not more now. Same for > access > restrictions to children pages. > > See http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization This is a new feature that I haven't tried yet - I'm running a 7.1.1 and 7.1.2 system. I look forward to upgrading and trying this out soon. > > The other big difference, to me, is in documentation. XWiki has > > changed a lot over the years, particularly in the API, > > This is not fully correct. A lot of new APIs have been introduced, showing the > dynamism of the XWiki community indeed. However, we take very seriously > backward-compatibility (so seriously that breaking it fails our build > automatically ;)). So all that worked are still supposed to work. Do you have > an example that you’ve noticed where it’s not true (it can happen from time > to time when we conscientiously decide to break a recent API that we think > nobody uses) . Again, I may be out of date here. I've really struggled to get the API documentation for 7.1. I see that things have been cleaned up a lot at http://platform.xwiki.org/xwiki/bin/view/DevGuide/API but the APIs still seem to be missing for versions between 5.0 and 7.4.3. Obviously the solution for me now would be to upgrade. > > > and a lot of the material discoverable on the web is out of date. > > Any example? That would help to fix them. Again this may be historical rather than present day. I'll certainly yell if I encounter examples in the future. When I first set about writing a component I googled around for examples and much of that was for the older plugin architecture, and I was too new to things to appreciate the difference. I think the API was also in a state of transition at the time, so properties available through the wiki context required awkward bridging classes that didn't make sense to noobs such as me. Incidentally, I think it could still be easier to write extensions for XWiki. Writing Groovy components within XWiki pages is neat, but (at least in 7.1) they don't work until someone manually visits the page a first time. This means some components stop working when the system is restarted. It also lacks access to a decent IDE interface to aide writing code - sometimes I end up copying and pasting between the wiki editor and Notepad++ so that I can get code formatting and syntax highlighting. > > Much of this difference is just a natural outcome of the proprietary vs. > open source backgrounds of each system. > > Well our goal is to be open source and still be good on all fronts! :) That's an admirable goal, and a formidable undertaking. Good luck! You've certainly got an impressive product. _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
