Re: [xwiki-devs] Improving the XWiki Development environment for traditional Java/JS Developers

On 4 juil. 2013, at 09:07, Paul Libbrecht wrote: course create the related file. processing instruction so that the export can do the converse. https://github.com/xwiki/xwiki-commons/tree/master/xwiki-commons-tools/xwik… So I've looked around a bit because just now would be a good time and I had an issue related to the Package class. I understand XWiki is using dom4j as internal xml representation. I understand every time the xml is read, it is using SAXReader. My first step would be to support xinclude parse=text in xml documents. That would allow me to package the source files (especially of the page content) in the xar zips together with the xml sources and thus have a source tree made of short handwritten xml sources, and content sources. Later on, this could be generalized to attachments, the maven xar plugin would need to convert the binaries to base64 which would also be included using xinclude. Now, I am left with finding the right place where the xar import of XWiki ingests the XML and add the XInclude feature to it (which Xerces supports) (other places do not need the xinclude). I have found com.xpn.xwiki.plugin.packaging.Package in the method fromXml and readFromXML. Are there the only places? These method sound called from readFromDir and Import which I would reformulate to allow relative resolution (URLs need to be provided to the XML parser then). This will create a dom that has "forgotten" the XInclude (except maybe an invisible trace) and thus would not bother further xml (de)-serialization. Alternatively, I'd post process the dom4j tree to perform the xinclude (might be easier). thank you for your guidance through the sea of xwiki code. Paul _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs