Re: [xwiki-devs] XAR source projects should allow source files

On 26 Aug 2016, at 18:33, Vincent Massol <vincent(a)massol.net> wrote: 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/DirectoryStructureforXWikiApp…. 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… 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.

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 <paul(a)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