> On 26 Aug 2016, at 14:03, Paul Libbrecht <p...@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 _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
