> 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.WebHome for 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 <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 _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
