14 Sep
2016
14 Sep
'16
7:58 a.m.
On Tue, Sep 13, 2016 at 10:29 PM, Vincent Massol <vincent(a)massol.net> wrote:
On 13 Sep 2016, at 20:49, Eduard Moraru
<enygma2002(a)gmail.com> wrote:
On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <vincent(a)massol.net> wrote:
Are we really sure that this strategy is realistic? I mean, if one core
module needs at some point, for some remote feature, to depend on the chart
macro, does that automatically make the chart macro core? IMO no
IMO it does. I don’t see how a core module could depend on a non core module. By
definition if a module depends on another, it means that the module that it depends on is
even “more core” than itself… And there’s no more core than core :)
On 13 Sep 2016, at 18:24, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Edy,
> On 13 Sep 2016, at 18:03, Eduard Moraru <enygma2002(a)gmail.com> wrote:
>
> Hi,
>
> Let`s think about active installs. The client module (i.e. the one doing
> the work and reporting) can be considered core, but the server module
(the
> one receiving and showing a UI of the
collected data) is not really core
> and can be moved to contrib. This will also fix the chart macro issue,
> since it's the server/ui module depending on it and not the client-api
one.
Indeed you’re completely right! Don’t know why I didn’t think about this
:)
Now that said, we might want to have other core stuff use the chart macro
in the future.
Are we really sure we’ll never want to use the chart macro in any core UI?
, otherwise
we end up saying that all dependencies of core modules are core as well
(could even argue the need to control the sources of all those dependencies
as well), which would be obviously bad.
Why is it bad? I don’t know any other definition and I’ve never heard of anything
different done elsewhere.
For me you only have 2 options if you find that a core module requires a dep on a
currently non core module:
1) Make that non core module a core module (ie move it)
2) Make the core module non core (ie move it out of core)
This question probably leads back
to the definition of core and what it implies.
We have a pretty good definition of core already:
- All modules that make up the base distribution. - Modules maintained and developed by the XWiki Core
Deve team (i.e. located in a repo in the XWiki organization on github)
About that, you did not answered my comment on the fact that you plan
to put "Knownledge Base" flavor (which will depends on various Contrib
extensions) in xwiki-platform.
As time progresses and as we’re able to reduce hard-coded and artifical dependencies in
core modules, we can extract more and more as non core.
The only option that I see would be to consider that we can core modules that are located
outside of the XWiki organization on github but I don’t feel that it is very convenient.
It would scatter core modules. It feels better to have all core modules grouped together
in a single place, especially since they should be released together.
In conclusion: we need to be very careful about modules that we extract from the core
since we don’t want to have to play yo-yo and move them back later in the future, as much
as possible. Better be conservative when in doubt.
For the case at hand, I wouldn’t move the chart macro for now. It seems core enough. Same
for the code macro (unfortunately, since that means keeping the jython dep in the core
too).
Another thought just for the sake of mentioning it:
* We could consider that all the UIs that are currently in xwiki-platform are not core
and that only the APIs are core. This would mean that the base distribution would lead to
an empty wiki. And all UIs would be brought by the flavors.
* The consequence is that a lot of macros could be moved out: chart, code, etc.
However this is a bit too drastic and harsh to do ATM IMO. So I don’t think it would be a
good idea FTM.
Thanks
-Vincent
--
Thomas Mortagne
Thanks,
Eduard
>
> Thanks
> -Vincent
>
>> Thanks
>> -Vincent
>>
>>> Thanks,
>>> Eduard
>>>
>>> On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <vincent(a)massol.net>
> wrote:
>>>
>>>>
>>>>> On 11 Sep 2016, at 19:24, Vincent Massol <vincent(a)massol.net>
wrote:
>>>>>
>>>>> Hi devs,
>>>>>
>>>>> I’d like to propose:
>>>>> * move out the Chart Macro + Renderer to Contrib since it’s not
core.
>>>>> * still depend on it in the XE distribution for now. However if
> everyone
>>>> feels that it’s not needed to have it by default for users and that
> it’s
>>>> better to let them install it, I’m also fine. But right now I prefer to
>>>> have it by default.
>>>>>
>>>>> WDYT?
>>>>
>>>> hmm there’s a small problem… Right now the Active Installs module uses
> the
>>>> chart macro…
>>>>
>>>> And Statistics UI too. I guess this one could be moved to contrib
> easily
>>>> (we don’t bundle it anymore by defaultà.
>>>>
>>>> However for ActiveInstalls it’s more complex, unless we don’t want to
>>>> consider it core but I don’t think we want that…
>>>>
>>>> So it means either we stop using the chart macro there (which would be
> a
>>>> shame) or we consider the chart macro core…
>>>>
>>>> Any idea?
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>> Thanks
>>>>> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs