> On 26 Aug 2016, at 18:33, Vincent Massol <vinc...@massol.net> wrote: > >> >> On 26 Aug 2016, at 13:50, Vincent Massol <vinc...@massol.net> wrote: >> >> Hi Paul, >> >> I’ve finally taken the time to read this discussion (a bit quickly for the >> last mail though, I admit ;)). >> >> Let me give my POV: >> >> * What I understand is that you’re not proposing to change the XAR format >> but to introduce some tooling to generate a XAR from a set of source files, >> at build time. Correct? >> >> * IMO we should not touch the existing XAR plugin. This is current the >> standard way to generate XAR files and we need to keep, if only for >> backward compatibility with existing sources. >> >> * IMO you should develop your tool as a new maven plugin in xwiki-contrib >> and use it on some contrib projects to validate and show to others how it >> works. Of course you can depend on the existing XAR plugin if you need tor >> reuse some code (it’s even possible to introduce a new api module if there’s >> an important need to share common code). >> >> * FTR this is exactly what Jean Simard as done with the XFF tools >> (https://github.com/xwiki-contrib/api-xff). He’s done is separately to >> validate it and show it. We need to know where we stand on XFF since it’s >> currently the most advanced POC that we have on introducing a new format for >> storing wiki pages in the SCM. It also supports both directions: from source >> to XAR and from wiki pages to source. I’m planning to check what’s missing >> in that progress to be able to use it (not much IMO). >> >> * If you were to develop your maven plugin, you would just compete with the >> XFF code. This is fine, although I’d have preferred that we spend our time >> finishing the XFF work. It’s your time so your choice though. In the future, >> we’ll be able to choose which solution we want to use between the 3 that >> will exist (current XAR plugin, XFF solution and your solution). >> >> * FTR Fabio had also worked on this topic in the past, see >> http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApplications. >> Caleb has also worked on something related: >> https://github.com/xwiki-contrib/xwiki-tools-node > > More notes: > > - Caleb’s solution is working and is being used for some projects. For > example: > https://github.com/xwiki-contrib/realtime-wysiwyg/tree/master/src/xwiki > > Cons of Caleb solutions are listed at > http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApplications. > Main issue points IMO: > * There is no automated way to create this structure from code in the Wiki > (TODO) > • Still lacking a Maven job for building extensions (TODO). Requires nodejs > to build. > > - There’s also work done by Fabio here that I had missed: > https://github.com/fmancinelli/xwikifs. Fabio has chosen YAML, see > https://github.com/fmancinelli/xwikifs/tree/master/xwikifs-maven-plugin/src/it/xar/src/main/resources/Main.WebHomefor > an example. However I don’t know what is its status. There seems to be a > Maven XAR mojo written to generate a XAR file.
FTR here’s what Paul was saying in 2013 concerning xwikifs: http://markmail.org/message/az2mh65c6xuc47bp :) Thanks -Vincent > > So we have plenty of stuff that have been tried but none has been finished > and none are addressing the full needs. To summarize, so far I’ve found: > > * Caleb’s nodejs tool: https://github.com/xwiki-contrib/xwiki-tools-node > * Fabio’s xwikifs: https://github.com/fmancinelli/xwikifs > * Jean’s XFF: https://github.com/xwiki-contrib/api-xff > * Paul’s XInclude extension to the XAR plugin: > http://jira.xwiki.org/browse/XWIKI-13643 > > They all seem to be missing the ability to export wiki pages from a running > wiki into the source filesystem. > > Thanks > -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. >> >> 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. >> * 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). >> >> WDYT? >> >> Thanks >> -Vincent >> >> >>> On 22 Aug 2016, at 15:59, Paul Libbrecht <p...@hoplahup.net> wrote: >>> >>> >>> Hello fellow developers, >>> >>> many of you are developing XAR-packaged resources. The exchangeability >>> of these archives is one of the precious aspects of XWiki, I believe. >>> >>> However, if one see all the many GitHub-contributed xar packages, the >>> source is not there: it's in a Wiki with which one would "open it". A >>> pity since much of the content is code. >>> >>> I'd like to propose to allow XARs to be built form source code which is >>> true source that one edits. >>> Code files with their proper syntax coloring, editors, auto-completion, >>> search. Media-files that are edited with our tool of choice by a simple >>> double-click and not a complex pull, edit, and replace. >>> >>> Thus, my proposal is to allow inclusions within the XML files. >>> Inclusions should be of type: >>> - text to include page content or object properties (e.g. css of cssx >>> objects) >>> - attachments to include attached objects >>> >>> My current setup is documented here:http://jira.xwiki.org/browse/XWIKI-13643 >>> It does binaryInclude to generate base64 and textInclude to generate >>> XML-text. >>> Thus, I can advertise a github project which is a macro and whose >>> complex function is in a velocity file that is in a .vm file. However, I >>> do not need to explode everything, e.g. the text-content describing the >>> macro or (in this case too small) translation set. >>> >>> What do you think? >>> Should I rather generate complete attachment elements (name, length, >>> modif date, ...) instead of doing a binaryInclude that just generates >>> base64 ? >>> Is fetching files for inclusion beyond the boundaries of the project of >>> any use? (it is currently prohibited for safety) >>> >>> thanks in advance. >>> >>> Paul _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
