26 Aug
2016
26 Aug
'16
6:33 p.m.
On 26 Aug 2016, at 13:50, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Paul,
I’ve finally taken the time to read this discussion (a bit quickly for the last mail
though, I admit ;)).
Let me give my POV:
* What I understand is that you’re not proposing to change the XAR format but to
introduce some tooling to generate a XAR from a set of source files, at build time.
Correct?
* IMO we should not touch the existing XAR plugin. This is current the standard way to
generate XAR files and we need to keep, if only for backward compatibility with existing
sources.
* IMO you should develop your tool as a new maven plugin in xwiki-contrib and use it on
some contrib projects to validate and show to others how it works. Of course you can
depend on the existing XAR plugin if you need tor reuse some code (it’s even possible to
introduce a new api module if there’s an important need to share common code).
* FTR this is exactly what Jean Simard as done with the XFF tools
(https://github.com/xwiki-contrib/api-xff). He’s done is separately to validate it and
show it. We need to know where we stand on XFF since it’s currently the most advanced POC
that we have on introducing a new format for storing wiki pages in the SCM. It also
supports both directions: from source to XAR and from wiki pages to source. I’m planning
to check what’s missing in that progress to be able to use it (not much IMO).
* If you were to develop your maven plugin, you would just compete with the XFF code.
This is fine, although I’d have preferred that we spend our time finishing the XFF work.
It’s your time so your choice though. In the future, we’ll be able to choose which
solution we want to use between the 3 that will exist (current XAR plugin, XFF solution
and your solution).
* FTR Fabio had also worked on this topic in the past, see
http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApp….
Caleb has also worked on something related:
https://github.com/xwiki-contrib/xwiki-tools-node
More notes:
- Caleb’s solution is working and is being used for some projects. For example:
https://github.com/xwiki-contrib/realtime-wysiwyg/tree/master/src/xwiki
Cons of Caleb solutions are listed at
http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApp…. Main
issue points IMO:
* There is no automated way to create this structure from code in the Wiki (TODO)
• Still lacking a Maven job for building extensions (TODO). Requires nodejs to build.
- There’s also work done by Fabio here that I had missed:
https://github.com/fmancinelli/xwikifs. Fabio has chosen YAML, see
https://github.com/fmancinelli/xwikifs/tree/master/xwikifs-maven-plugin/src…
for an example. However I don’t know what is its status. There seems to be a Maven XAR
mojo written to generate a XAR file.
So we have plenty of stuff that have been tried but none has been finished and none are
addressing the full needs. To summarize, so far I’ve found:
* Caleb’s nodejs tool: https://github.com/xwiki-contrib/xwiki-tools-node
* Fabio’s xwikifs: https://github.com/fmancinelli/xwikifs
* Jean’s XFF: https://github.com/xwiki-contrib/api-xff
* Paul’s XInclude extension to the XAR plugin: http://jira.xwiki.org/browse/XWIKI-13643
They all seem to be missing the ability to export wiki pages from a running wiki into the
source filesystem.
Thanks
-Vincent
So for me the important part is for you to develop
your solution in a separate module in xwiki-contrib as a demonstator and possibly start
using it on some contrib project to validate it. The alternative is to work on XFF and
finish it.
Personally I’m not a big fan at all of modifying the existing XAR plugin for various
reasons:
* We don’t know yet what solution we’ll choose in the future. At this point in time I
even have a preference for XFF. So it wouldn’t be fair and nice to modify the existing XAR
plugin with your solution and then have to remove the code if we don’ want it in the
future.
* It will be much simpler for you to develop your own project in xwiki-contrib since
you’ll have commit access (which you won’t have in xwiki-commons).
WDYT?
Thanks
-Vincent
On 22 Aug 2016, at 15:59, Paul Libbrecht
<paul(a)hoplahup.net> wrote:
Hello fellow developers,
many of you are developing XAR-packaged resources. The exchangeability
of these archives is one of the precious aspects of XWiki, I believe.
However, if one see all the many GitHub-contributed xar packages, the
source is not there: it's in a Wiki with which one would "open it". A
pity since much of the content is code.
I'd like to propose to allow XARs to be built form source code which is
true source that one edits.
Code files with their proper syntax coloring, editors, auto-completion,
search. Media-files that are edited with our tool of choice by a simple
double-click and not a complex pull, edit, and replace.
Thus, my proposal is to allow inclusions within the XML files.
Inclusions should be of type:
- text to include page content or object properties (e.g. css of cssx
objects)
- attachments to include attached objects
My current setup is documented here:http://jira.xwiki.org/browse/XWIKI-13643
It does binaryInclude to generate base64 and textInclude to generate
XML-text.
Thus, I can advertise a github project which is a macro and whose
complex function is in a velocity file that is in a .vm file. However, I
do not need to explode everything, e.g. the text-content describing the
macro or (in this case too small) translation set.
What do you think?
Should I rather generate complete attachment elements (name, length,
modif date, ...) instead of doing a binaryInclude that just generates
base64 ?
Is fetching files for inclusion beyond the boundaries of the project of
any use? (it is currently prohibited for safety)
thanks in advance.
Paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs