> On 26 Aug 2016, at 18:51, Vincent Massol <[email protected]> wrote: > >> >> On 26 Aug 2016, at 13:24, Paul Libbrecht <[email protected]> wrote: >> >> Guillaume, >> >> The risk of dead code is always present at a developer. >> But the addition of inclusions seems to make this risk higher for you. >> >> Obviously we develop on very different wikis. >> Mine tends to be having several development traces, often parallel, >> sometimes not, and I will only reinstall if I really need it. >> When developing xars, you seem to be trusting that yours contain just a few. >> >> Because mine is crowdy, I will not trust a XAR export and will only pick >> the necessary files and/or elements form a xar export, if at all, or >> undergo a deep cleaning (which is typical at start). >> >> Because yours (I assume) is somewhat clean, you trust a xar export and >> commit it the eyes shut. >> Thus introducing an include that would be forgotten makes it probable >> for you and not for me, which is what you state. >> >> What I can offer is to add to my ready available code that the validate >> Mojo to check that no file that is not included in in the source tree. >> Useful? > > Useful but not enough IMO. This looks like just a workaround and it still > means some manual action to do after you’ve export your XAR into the source > tree. You still need to manually convert the document content which is > XML-encoded as a non-xml encoded content in the separate file. > > BTW on this topic, our XAR export should really use CDATA construct and stop > encoding the content. This is just a major PITA. > > Another idea is to offer 2 new Mojos in the XAR plugin: > > * mvn xar:deploy. This would push the sources into a running XWiki. The URL > to be used would be defined as maven properties (and so would be the import > options: overwrite, backup pack, etc). > > * mvn xar:fetch. This would do the opposite and it would accept 2 modes. Mode > 1: it would fetch new versions of existing files in the source directory > structure by fetching them from a running XWiki. Mode 2: there could be some > maven property to define the name of a space it should fetch from and it > would fetch all content inside that space. > > Now let’s come back to Paul’s proposal. The fetch operation could check the > current source file in the filesystem prior to the fetching an find all > xinclude and when it fetches a new version of that file (i.e. of the page), > it would replace the content with the xinclude it had found and copy the > content(s) in their separate file(s). > > This would allow not loosing the xincludes. And it would automate the whole > process even more. > > WDYT? > > FTR I find Paul’s idea quite clever with XInclude. I don’t think it’s our > final solution but it’s a clever one that addresses one need: that of being > able to use desktop tools to edit various file types (css, js, plain text). > > So to conclude and while waiting for more elaborate and final solutions, I’d > agree with Paul’s idea but I think we need: > > * Modify XWiki’s export to use CDATA instead of xml-encoding the contents. > This allows to more easily and manually copy content into separate files.
BTW on a related note, I was wondering if XInclude allows including non-XML encoded content. I’ve found https://msdn.microsoft.com/en-us/library/aa302291.aspx#xinc_topic4 which seems to indicate it’s supported (with parse=text and by using the encoding attribute too). Thanks -Vincent > * Implement the 2 mojos I mentioned above which should automate nicely our > process + avoid loosing xincludes. > * Paul’s idea of generating a warning if there’s a file in the tree that > doesn’t have a corresponding xinclude. > > WDYT? > > Thanks > -Vincent > >> Offering a diff is tempting but it's a lot more complex I feel (e.g. >> it's better if it's three way which developers rarely all have on a >> single disk, one or two of them being on a versioning server). >> >> Paul >> >> >> Guillaume Delhumeau wrote: >>> I would be very concerned if we have wiki pages with dead code in some >>> repository. >>> >>> I am very skeptical, because if we cannot rely on the standard exporter to >>> generate the source correctly, who will use these source files? When you >>> develop an application, do you write it in the XML page in your repository >>> or directly in your wiki? >>> >>> I am a bit conservative here and I don't want to block you, but I really >>> wonder if the advantages you mention worth the pain of being sure we don't >>> have dead code, and manually cutting/pasting some bit of the code from a >>> file to an other everytime you commit a page (and I do it often). >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
