10 May
2016
10 May
'16
10:12 p.m.
Hi devs,
Following our strategy of moving non-core extensions of platform in xwiki-contrib I’d like
to discuss moving non-core modules of xwiki-rendering into xwiki-contrib.
My real need ATM is to know where I should commit the Markdown renderer I’ve been working
on as a proof of concept. It’s working but not everything is supported yet and I don’t
plan nor want to commit to make it work in the near future. I also don’t want to put the
burden of maintaining it on the xwiki core dev team. And I also feel it should be located
in the same module where the Markdown parser is located. So one solution is to move the
Markdown syntax module into xwiki-contrib, as a whole.
Now, if we do this for the markdown module we might as well agree to do it for other
non-core modules, namely:
- some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook, doxia, jspwiki, tex
(+ markdown of course)
- some macro transformations: linkchecker, wikiword
- some macros like: the ctsreport one and the jira macro
WDYT?
Thanks
-Vincent
11 May
11 May
9:20 a.m.
New subject: [xwiki-devs] [Brainstorming] Move non-core modules of xwiki-rendering in xwiki-contrib
+1
Most of the stuff you`ve mentioned is not even discoverable in the default
distribution without reading the docs so it`s pointless IMO to have it by
default and we should let the admin install it when needed.
Thanks,
Eduard
On Tue, May 10, 2016 at 11:12 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
Following our strategy of moving non-core extensions of platform in
xwiki-contrib I’d like to discuss moving non-core modules of
xwiki-rendering into xwiki-contrib.
My real need ATM is to know where I should commit the Markdown renderer
I’ve been working on as a proof of concept. It’s working but not everything
is supported yet and I don’t plan nor want to commit to make it work in the
near future. I also don’t want to put the burden of maintaining it on the
xwiki core dev team. And I also feel it should be located in the same
module where the Markdown parser is located. So one solution is to move the
Markdown syntax module into xwiki-contrib, as a whole.
Now, if we do this for the markdown module we might as well agree to do it
for other non-core modules, namely:
- some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook,
doxia, jspwiki, tex (+ markdown of course)
- some macro transformations: linkchecker, wikiword
- some macros like: the ctsreport one and the jira macro
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:47 a.m.
On 10 May 2016, at 23:12, Vincent Massol
<vincent(a)massol.net> wrote:
Hi devs,
Following our strategy of moving non-core extensions of platform in xwiki-contrib I’d
like to discuss moving non-core modules of xwiki-rendering into xwiki-contrib.
My real need ATM is to know where I should commit the Markdown renderer I’ve been working
on as a proof of concept. It’s working but not everything is supported yet and I don’t
plan nor want to commit to make it work in the near future. I also don’t want to put the
burden of maintaining it on the xwiki core dev team. And I also feel it should be located
in the same module where the Markdown parser is located. So one solution is to move the
Markdown syntax module into xwiki-contrib, as a whole.
Now, if we do this for the markdown module we might as well agree to do it for other
non-core modules, namely:
- some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook, doxia, jspwiki, tex
(+ markdown of course)
- some macro transformations: linkchecker, wikiword
- some macros like: the ctsreport one and the jira macro
WDYT?
Note that one consequence could be that we should deprecate the configured syntaxes, i.e.
the xwiki.rendering.syntaxes property in xwiki.cfg. Or at least don’t define it by
default.
This property is there since all syntaxes are bundled by default and admin may not want
their users to use all available syntaxes.
What would be nice is that, if we move some syntaxes out, when an admin installs them as
extension with the EM, they become active without having to stop and restart the wiki. I
guess we could implement this with http://jira.xwiki.org/browse/XWIKI-12474 and by default
when a new syntax extension is installed, it’s active i.e. do the same as we do for the
Applications Panel.
Thanks
-Vincent
Thanks
-Vincent
6:06 p.m.
New subject: [xwiki-devs] [Brainstorming] Move non-core modules of xwiki-rendering in xwiki-contrib
On Wed, May 11, 2016 at 10:47 AM, Vincent Massol <vincent(a)massol.net> wrote:
Another consequence is that it will be harder to see if a change in the
rendering API breaks one of the available syntaxes. But this is acceptable.
+1
Thanks,
Marius
On 10 May 2016, at 23:12, Vincent Massol
<vincent(a)massol.net> wrote:
Hi devs,
Following our strategy of moving non-core extensions of platform in
xwiki-contrib
I’d like to discuss moving non-core modules of
xwiki-rendering into xwiki-contrib.
My real need ATM is to know where I should commit the Markdown renderer
I’ve been
working on as a proof of concept. It’s working but not everything
is supported yet and I don’t plan nor want to commit to make it work in the
near future. I also don’t want to put the burden of maintaining it on the
xwiki core dev team. And I also feel it should be located in the same
module where the Markdown parser is located. So one solution is to move the
Markdown syntax module into xwiki-contrib, as a whole.
Now, if we do this for the markdown module we might as well agree to do
it for
other non-core modules, namely:
- some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook,
doxia,
jspwiki, tex (+ markdown of course)
- some macro transformations: linkchecker,
wikiword
- some macros like: the ctsreport one and the jira macro
WDYT?
Note that one consequence could be that we should deprecate the configured
syntaxes, i.e. the xwiki.rendering.syntaxes property in xwiki.cfg. Or at
least don’t define it by default.
This property is there since all syntaxes are bundled by default and admin
may not want their users to use all available syntaxes.
What would be nice is that, if we move some syntaxes out, when an admin
installs them as extension with the EM, they become active without having
to stop and restart the wiki. I guess we could implement this with
http://jira.xwiki.org/browse/XWIKI-12474 and by default when a new syntax
extension is installed, it’s active i.e. do the same as we do for the
Applications Panel.
Thanks
-Vincent
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:31 p.m.
On 11 May 2016, at 19:06, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, May 11, 2016 at 10:47 AM, Vincent Massol <vincent(a)massol.net> wrote:
Another consequence is that it will be harder to see if a change in the
rendering API breaks one of the available syntaxes. But this is acceptable.
yes, we would add the jobs in the CI.
Thanks
-Vincent
On 10 May 2016, at 23:12, Vincent Massol
<vincent(a)massol.net> wrote:
Hi devs,
Following our strategy of moving non-core extensions of platform in
xwiki-contrib
I’d like to discuss moving non-core modules of
xwiki-rendering into xwiki-contrib.
My real need ATM is to know where I should commit the Markdown renderer
I’ve been
working on as a proof of concept. It’s working but not everything
is supported yet and I don’t plan nor want to commit to make it work in the
near future. I also don’t want to put the burden of maintaining it on the
xwiki core dev team. And I also feel it should be located in the same
module where the Markdown parser is located. So one solution is to move the
Markdown syntax module into xwiki-contrib, as a whole.
Now, if we do this for the markdown module we might as well agree to do
it for
other non-core modules, namely:
- some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook,
doxia,
jspwiki, tex (+ markdown of course)
- some macro transformations: linkchecker,
wikiword
- some macros like: the ctsreport one and the jira macro
WDYT?
Note that one consequence could be that we should deprecate the configured
syntaxes, i.e. the xwiki.rendering.syntaxes property in xwiki.cfg. Or at
least don’t define it by default.
+1
Thanks,
Marius
>
> This property is there since all syntaxes are bundled by default and admin
> may not want their users to use all available syntaxes.
>
> What would be nice is that, if we move some syntaxes out, when an admin
> installs them as extension with the EM, they become active without having
> to stop and restart the wiki. I guess we could implement this with
> http://jira.xwiki.org/browse/XWIKI-12474 and by default when a new syntax
> extension is installed, it’s active i.e. do the same as we do for the
> Applications Panel.
>
> Thanks
> -Vincent
>
>
>>
>> Thanks
>> -Vincent
10:16 a.m.
New subject: [xwiki-devs] [Brainstorming] Move non-core modules of xwiki-rendering in xwiki-contrib
+1
On Tue, May 10, 2016 at 10:12 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
Following our strategy of moving non-core extensions of platform in xwiki-contrib I’d
like to discuss moving non-core modules of xwiki-rendering into xwiki-contrib.
My real need ATM is to know where I should commit the Markdown renderer I’ve been working
on as a proof of concept. It’s working but not everything is supported yet and I don’t
plan nor want to commit to make it work in the near future. I also don’t want to put the
burden of maintaining it on the xwiki core dev team. And I also feel it should be located
in the same module where the Markdown parser is located. So one solution is to move the
Markdown syntax module into xwiki-contrib, as a whole.
Now, if we do this for the markdown module we might as well agree to do it for other
non-core modules, namely:
- some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook, doxia, jspwiki, tex
(+ markdown of course)
- some macro transformations: linkchecker, wikiword
- some macros like: the ctsreport one and the jira macro
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
10:41 a.m.
New subject: [xwiki-devs] [Brainstorming] Move non-core modules of xwiki-rendering in xwiki-contrib
+1
Thanks,
Caty
On Wed, May 11, 2016 at 11:16 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
wrote:
> +1
>
> On Tue, May 10, 2016 at 10:12 PM, Vincent Massol <vincent(a)massol.net>
wrote:
> > Hi devs,
> >
> > Following our strategy of moving non-core extensions of platform in
> xwiki-contrib I’d like to discuss moving non-core modules of
> xwiki-rendering into xwiki-contrib.
> >
> > My real need ATM is to know where I should commit the Markdown renderer
> I’ve been working on as a proof of concept. It’s working but not everything
> is supported yet and I don’t plan nor want to commit to make it work in the
> near future. I also don’t want to put the burden of maintaining it on the
> xwiki core dev team. And I also feel it should be located in the same
> module where the Markdown parser is located. So one solution is to move the
> Markdown syntax module into xwiki-contrib, as a whole.
> >
> > Now, if we do this for the markdown module we might as well agree to do
> it for other non-core modules, namely:
> >
> > - some syntaxes: mediawiki, twiki, apt, confluence*, creole, docbook,
> doxia, jspwiki, tex (+ markdown of course)
> > - some macro transformations: linkchecker, wikiword
> > - some macros like: the ctsreport one and the jira macro
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
3050
days inactive
3051
days old
6 comments
5 participants
participants (5)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol