26 Aug
2016
26 Aug
'16
8:37 p.m.
On 26 Aug 2016, at 18:51, Vincent Massol
<vincent(a)massol.net> wrote:
Another option is to modify xar:format to always extract content + textarea properties +
attachments into separate files. And agree that’s we’re ok to switch to this
representation.
Thanks
-Vincent
On 26 Aug 2016, at 13:24, Paul Libbrecht <paul(a)hoplahup.net> 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).