Guillaume, sure, this is *doable* but it can also be done at discretion. E.g. you'd only copy from the exploded xar the other files you copied but not the source. Also, if you replace the XML files with those of the XARs, you'll just ignore the sources, since you've removed the includes.
So, I really think that this is a progress. I agree an XFF to XAR converter would be more interesting but my patch is ready to be applied. A XAR generator is not yet. paul > Guillaume Delhumeau <mailto:[email protected]> > 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:[email protected]> > 23 August 2016 at 13:11 > 2016-08-23 12:36 GMT+02:00 Paul Libbrecht <[email protected]>: > >> 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 before. >>> 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. >> 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. > > > In practice, this is the only manual step. I do a diff of the modifications > I have made and I revert all changes that are meaningless. But it's quick & > easy using my IDE (IntelliJ). I know some developers here do the same. The > only issue is when the XAR format have changed: some fields are not ordered > in the same way, and it makes harder to compute the real diff. > > > >> 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 >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > Paul Libbrecht <mailto:[email protected]> > 23 August 2016 at 12:36 > 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 before. >> 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. > 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 > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > Thomas Mortagne <mailto:[email protected]> > 23 August 2016 at 12:28 > On Tue, Aug 23, 2016 at 12:26 PM, Thomas Mortagne > <[email protected]> wrote: >> On Tue, Aug 23, 2016 at 12:17 PM, Paul Libbrecht <[email protected]> wrote: >>>>> 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 chance >>> of uptake? > >>> What does it take for me to get the patch accepted? > > 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. > >>> thanks >>> >>> Paul >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> -- >> Thomas Mortagne > > > > Thomas Mortagne <mailto:[email protected]> > 23 August 2016 at 12:26 > On Tue, Aug 23, 2016 at 12:17 PM, Paul Libbrecht <[email protected]> wrote: >>>> 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 chance >> of uptake? >> What does it take for me to get the patch accepted? >> >> thanks >> >> Paul >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
