> On 13 Sep 2016, at 20:49, Eduard Moraru <[email protected]> wrote: > > On Tue, Sep 13, 2016 at 7:37 PM, Vincent Massol <[email protected]> wrote: > >> >>> On 13 Sep 2016, at 18:24, Vincent Massol <[email protected]> wrote: >>> >>> Hi Edy, >>> >>>> On 13 Sep 2016, at 18:03, Eduard Moraru <[email protected]> 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? >> > > 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 :) > , 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) 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 > Thanks, > Eduard > > >> >> Thanks >> -Vincent >> >>> Thanks >>> -Vincent >>> >>>> Thanks, >>>> Eduard >>>> >>>> On Sun, Sep 11, 2016 at 8:45 PM, Vincent Massol <[email protected]> >> wrote: >>>> >>>>> >>>>>> On 11 Sep 2016, at 19:24, Vincent Massol <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
