On 26 Aug 2016, at 14:03, Paul Libbrecht
<paul(a)hoplahup.net> wrote:
Hello VIncent,
So for me the important part is for you to
develop your solution in a separate module in xwiki-contrib as a demonstator and possibly
start using it on some contrib project to validate it. The alternative is to work on XFF
and finish it.
Well. That brings the question back: how many are using it?
Obviously, I see almost no-one.
ofc since it isn’t finished and has never been promoted and the xwiki product team has not
even decided whether they’d like to use it or not for the apps in the platform repo...
As long as:
- it is not complete
- it is not used by developers big time
... it will not be considered useful.
So... requesting to "go away" is very close to what you're asking, I feel.
Too bad you’re seeing it this way but I was actually trying to help you, so that you could
progress (not be blocked) and show something (to convince people).
Now if your point is that either your tool should be used by the xwiki dev team or you
don’t want to spend time working on it, then it requires a lot more discussions and
it's required that it solves the issue of moving from wiki pages to sources which you
haven’t addressed (but which XFF has).
To repeat myself, ATM, with my hat of xwiki dev team member, I prefer the XFF solution
because 1) it’s a complete solution and 2) it’s following the direction we want to take
(Filters). We still need to assess how much work remain but I’m confident it’s not too
much.
In the contrary, I believe that changing the XAR
plugin in a fully
conservative way is the way to go if one wants incremental progress.
As soon as the code is in, it’s the work of the xwiki dev team to support it even though
we may not even be using it. What’s the point?
Honestly I don’t understand why you cannot put your code in xwiki-contrib under a
different maven plugin than the XAR one. Name it XAR2 if you want. As for using it in a
project it’s a simple as declaring 3 lines so that cannot be the issue.
Can it be that you did not notice, it is fully
backwards compatible?
What I haven’t fully understood is how would the sources of wiki pages look like in the
file system with your proposal. Do you have an example?
Can I test it somewhere so that I can fully understand your technical solution?
Personally I’m
not a big fan at all of modifying the existing XAR plugin for various reasons:
* We don’t know yet what solution we’ll choose in the future. At this point in time I
even have a preference for XFF. So it wouldn’t be fair and nice to modify the existing XAR
plugin with your solution and then have to remove the code if we don’ want it in the
future.
But obviously the time has not been invested about it.
All issues are closed for XFF.
So let’s do it! :)
It hasn’t been invested more because the xwiki dev team doesn’t have such a pressing need
compared to other stuff, that’s all. Now I’ve personally been wanting to review it, make
it work and make a proposal on the list about using it for the platform github repo.
Now there are still problems probably. For example even though it supports exporting, it’s
not convenient unless it’s bundled by default (since otherwise you’d need to install the
extension everytime when you’re in dev mode, which is a pain). So we’d need to agree we
want to bundle it by default for example.
* It will be
much simpler for you to develop your own project in xwiki-contrib since you’ll have commit
access (which you won’t have in xwiki-commons).
That's a moot criterion.
My code is really not a big change and also not very high risk.
What I fail to understand is why you don’t want to commit your code in contrib. XWiki is a
platform with extensions. You don’t need to be in the core to be able to contribute an
extension to XWiki (XAR plugin is core).
Thanks
-Vincent
Paul