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. * 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