16 May
2016
16 May
'16
10:45 a.m.
Hi Bryn,
Thanks again, see below.
On 16 May 2016, at 00:40, Bryn Jeffries
<bryn.jeffries(a)sydney.edu.au> wrote:
Vincent wrote:
Yes, it could have some more love for sure ;) However, it’s supposed to be usable and it’s
not competing with dedicated products such as redmine, jira, etc. Dedicated products will
always be better. The goal is that if your needs are small, you can instal this extension
and it’ll do the job and you don’t need to install another product.
What we should be doing is integrate with external issue trackers.
Regarding JIRA for example, we have strong integration with it using our JIRA macro our
our JIRA scripting API.
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
There’s a difference here. XWiki’s goal is not to compete on the developer spectrum but
more on the general business one, see
http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki-vs-Confluence#HIntermsofma…
Now, I personally think that XWiki should have a great appeal to devs since it’s full
programmable and scriptable.
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
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.
I’m eager to get your feedback on this!
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 The other big difference, to me, is in documentation.
XWiki has
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.
Yes, we only maintain documentation for the latest version of XWiki on xwiki.org (not
enough manpower to have decent doc for several versions ATM).
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) . and a lot of the material discoverable on the web is
out of date.
They do always work actually, even when restarting. The issue is that if you write in
Groovy for example, you need Programming Rights (PR) since the language can access
anything, including the file system and more. You give PR to a page when a user with PR
saves it. And you loose PR when a user without PR saves the page. So the page will work
till someone without PR saves it. To circumvent this, pages requiring PR could be
right-protected so that only user with PR can edit them for example.
EDIT: I think you actually meant writing a groovy script to register some code as a
component. Actually we have wiki components for that:
http://extensions.xwiki.org/xwiki/bin/view/Extension/WikiComponent+Module
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.
Keep the feedback coming! Even the bad one, we need to learn what we should improve.
Thanks!
-Vincent
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.