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

Guillaume Delhumeau <mailto:guillaume.delhumeau@xwiki.com> 23 August 2016 at 13:19 Of course, we could still change our workflow and copy/paste source contents manually. Not sure it's gonna be more effective. So I prefer the XFF approach (except that I would love having a Nested Document terminology instead of the current Space/Document one). 2016-08-23 13:11 GMT+02:00 Guillaume Delhumeau < Guillaume Delhumeau <mailto:guillaume.delhumeau@xwiki.com> 23 August 2016 at 13:11 2016-08-23 12:36 GMT+02:00 Paul Libbrecht &lt;paul(a)hoplahup.net&gt;et>: > Thomas Mortagne wrote: >> It takes the following IMO: >> * it works >> * it does not break any retro compatibility > both are claimed. > There are unit tests. > The only danger of breaking anything is if dom4j does not faithfully > restore the XML source. I believe this can be ignored just as it has > been ignored by the implementation of transformations. >> (probably not enabled by default for example) > No, it is enabled by default. > I could replace the dom4j output by a file copy if no relevant elements > are found. > > Note however, that it operates on elements that were never allowed

In practice, this is the only manual step. I do a diff of the

I have made and I revert all changes that are meaningless. But it's

easy using my IDE (IntelliJ). I know some developers here do the same.

only issue is when the XAR format have changed: some fields are not

in the same way, and it makes harder to compute the real diff. Paul Libbrecht <mailto:paul@hoplahup.net> 23 August 2016 at 12:36 Thomas Mortagne wrote: both are claimed. There are unit tests. The only danger of breaking anything is if dom4j does not faithfully restore the XML source. I believe this can be ignored just as it has been ignored by the implementation of transformations. No, it is enabled by default. I could replace the dom4j output by a file copy if no relevant elements are found. Note however, that it operates on elements that were never allowed

I believe this is best practice to insure that the wiki does not insert you surprise elements such as the author name or the edit comment. Is this practice not corresponding at all what others are doing? Using an XML-diff might be answering Guillaume's point... That's not completely trivial. Paul _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs Thomas Mortagne <mailto:thomas.mortagne@xwiki.com> 23 August 2016 at 12:28 On Tue, Aug 23, 2016 at 12:26 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; wrote: > On Tue, Aug 23, 2016 at 12:17 PM, Paul Libbrecht &lt;paul(a)hoplahup.net&gt;

>>>> What I obtain after mvn package is a file my-application.xff. >>>>> I can't seem to import that. Should I be able to? >>> Not trough XAR tools no, it's completely different format. >> So what needs to be done here is a converter which is a lot bigger than >> a packager. > Which is what I indicated: you just use XFF filter (which already > exist) in input and XAR filter (which also already exist) as output. > >> We'll see what Jean says. >> >> >> >> In the meantime, do I understand at least that an enrichment to the >> xar-mojo is a more conservative approach that might have a better

It takes the following IMO: * it works * it does not break any retro compatibility (probably not enabled by default for example) Now Guillaume has a point. The issue you will quickly have as soon as you start using this is that you HAVE to modify your XAR trough filesystem because you can't edit it in XWiki and export it anymore. That is if you don't provide any tool to export this kind of XAR extension. Thomas Mortagne <mailto:thomas.mortagne@xwiki.com> 23 August 2016 at 12:26 On Tue, Aug 23, 2016 at 12:17 PM, Paul Libbrecht &lt;paul(a)hoplahup.net&gt;

Which is what I indicated: you just use XFF filter (which already exist) in input and XAR filter (which also already exist) as output.