On Thu, Jun 9, 2016 at 2:17 PM, Vincent Massol <[email protected]> wrote: > >> On 09 Jun 2016, at 13:45, Eduard Moraru <[email protected]> wrote: >> >> Hi, >> >> As far as I can see, you want to make sure that the user installs the Tour, > > Yep > >> for example, so that it is executed at the right time. However, why not let >> the flavor take care of this? Since the user will be choosing a flavor to >> install, it would also contain the tour (if it needs it) and everything >> will be set up. > > That wouldn’t work for 2 reasons: > * You only pick a flavor when you start with an empty wiki. So this isn’t the > case for Jetty/HSQLDB distribution which is the most important packaging for > people trying out XWiki. > * We would have 2 flavors: the default one (and we would need somehow to > prevent users from installing it, basically making the flavor useless) and > the other one which would be the recommended one. > > The goal of the idea I sent this morning is to have a single runtime flavor > provided by the XWiki Core dev team that is generic but as useful as possible > to users. > >> For additional extensions that the admin wants to install, >> we have the EM UI and we can have recommended extensions displayed there. >> >> An extra step just for the recommended extensions is too much IMO and just >> gets in the way. > > FTR This is exactly what happens when you install several softwares including > Jenkins 2, IntelliJ IDEA and more. > >> We still control what the standard flavor contains (tour, CK, etc.) and we >> still control what (contrib) extensions to recommend in the EM UI. IMO, >> that is enough. > > Ah I see what you mean. The other goal of the last proposal is to not have to > bundle any extension (that’s really important IMO), ie. the XWiki Core Dev > team doesn’t bundle any non xwiki github org code. Users can install contrib > stuff at runtime and pick the version they want/need. > > In addition this makes it possible for users to use the latest version of the > extensions. For example: imagine that we release XWiki 8.2 with a dependency > on CKEditor v1.7. Now, in the meantime CKEditor 1.8 is released. If we were > providing a flavor for it in XWiki 8.2 then users wouldn’t be able to install > version 1.8
This is true only for core jar extensions. CKEditor is a XAR. > > Thanks > -Vincent > >> Thanks, >> Eduard >> >> On Thu, Jun 9, 2016 at 2:12 PM, Ecaterina Moraru (Valica) <[email protected] >>> wrote: >> >>> I think that if we are to have Recommended extensions inside e.x.o and EM, >>> I would consider it a bit too much to have them also in DW. But maybe this >>> is another discussion. >>> >>> Thanks, >>> Caty >>> >>> On Thu, Jun 9, 2016 at 1:50 PM, Vincent Massol <[email protected]> wrote: >>> >>>> >>>>> On 09 Jun 2016, at 11:15, Ecaterina Moraru (Valica) <[email protected] >>>> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Where are the Flavors in this proposal? >>>> >>>> IMO Flavors don’t change; they’re still there and you still get them when >>>> you start with an empty wiki. When you start an empty wiki you pick the >>>> flavor you want and on the configuration screen, there are some >>> recommended >>>> extensions that are proposed. I think that’s the difference: flavors are >>> a >>>> fixed set of extensions. The Recommended extensions screen is just for >>>> optional stuff that you may want. If the recommended extensins are >>> brought >>>> as part of the flavor (ie if they are already installed) then they won’t >>> be >>>> suggested on the configuration screen. >>>> >>>> Basically flavors are distribution. Once you install a distribution you >>>> can still install additional extensions by going to the Extension >>> Manager. >>>> However we make the user’s file easier when he starts the first time by >>>> proposing some extensions. >>>> >>>> This provides 2 advantages: >>>> * We bring extensions that we deem important but that are not maintainted >>>> by the xwiki core dev team to the user. He doesn’t need to discover the >>> EM >>>> UI nor find out which extensions are super nice for me. >>>> * It allows to propose some extensions that need to run early in the >>>> process, such as the Tour (the user needs the Tour to know how to reach >>> the >>>> EM UI ;)). >>>> >>>> Another way of viewing this is that it’s a new feature of the EM/DW UI. >>>> The EM/DW module would provide a Recommended Extensions view as a Wizard >>>> when XWiki runtime starts the first time (and at each upgrade). Now what >>> we >>>> would need to be careful about is not drowning the user under 50 >>>> recommended extensions or it would loose its power. I think this config >>>> wizard view should focus on Extensions that are super useful for getting >>>> started. Then later one the user could go to the EM UI and get a full >>> list >>>> of Recommended Extensions, not just the one important for getting >>> started. >>>> >>>> WDYT? >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> Thanks, >>>>> Caty >>>>> >>>>> On Thu, Jun 9, 2016 at 12:01 PM, Vincent Massol <[email protected]> >>>> wrote: >>>>> >>>>>> Hi everyone, >>>>>> >>>>>> Thanks for the replies. I’m listening of course to everyone and I’ve >>>> tried >>>>>> in this mail to take all answers into account. >>>>>> >>>>>> First, let me state our current strategy and an alternative that I’ve >>>> been >>>>>> thinking about this morning under my shower ;) >>>>>> >>>>>> Current Voted Strategy >>>>>> ================== >>>>>> >>>>>> * Deliver an XWiki Runtime that is the best possible generic runtime >>>> (i.e. >>>>>> most usable, most useful). >>>>>> * As a consequence, remove all modules that vertical modules (i.e. >>> that >>>>>> are clearly not useful to all flavors), such as FAQ, Blog, etc. Move >>>> them >>>>>> to xwiki-contrib >>>>>> * I want to stress out that the current voted strategy is not to >>>> produce a >>>>>> minimalist runtime >>>>>> >>>>>> New Strategy Proposal >>>>>> ================== >>>>>> >>>>>> I’ve tried to reconcile all the use cases listed in this thread before >>>> and >>>>>> I hope this proposal could be a good middle ground. In any case I >>> found >>>> it >>>>>> worth debating to see if it could work. >>>>>> >>>>>> Also note that one aspect that we must not forget (and that led to the >>>>>> last proposal I sent on this thread) and that people tend to forget, >>> is >>>>>> the time it takes to support various versions of XE in an extension >>> and >>>> the >>>>>> manpower that exists in the xwiki community (don’t forget that >>>> everything >>>>>> we do is a tradeoff; if you support another version of XE in an >>>> extension, >>>>>> it means you’re not coding an important improvement or fixing an >>>> important >>>>>> bug in the platform). >>>>>> >>>>>> So here’s the idea: >>>>>> >>>>>> * Change the purpose of the XWiki Github organization from the voted >>> one >>>>>> described above to be: Provide a minimalist runtime. >>>>>> * Since working in this direction will not happen overnight, the idea >>>>>> would be to very slowly take out modules, starting with obvious ones. >>>>>> * The issue that this strategy raises is that users will not get a >>> good >>>>>> user experience since lots of things will be lacking and this is where >>>> my >>>>>> new idea fills the gap: >>>>>> ** The first time (or whenever you upgrade) your run the XWiki Runtime >>>> (be >>>>>> it whether your run the HSQLDB/Jetty packaging or any other packaging) >>>> you >>>>>> get a Configuration wizard >>>>>> ** This Configuration Wizard suggest some recommended extensions that >>>> the >>>>>> XWiki Core Dev Team hand-pick. We would start with 2: >>>>>> *** Propose to the user to run a Tour to learn how to use XWiki (it >>>> would >>>>>> install the Home Page Tour which depends on the Tour app) >>>>>> *** Propose to the user to install the CKEDitor WYSIWYG editor (by >>>> default >>>>>> we would only propose the wiki editor - We’ll need to get rid of the >>> GWT >>>>>> editor, probably make it an extension) >>>>>> >>>>>> Pros: >>>>>> * The XWiki Core Dev Team continues to work on core stuff and as time >>>>>> progresses we move out non core stuff >>>>>> * This allows more people to contribute to the non-core stuff in the >>>>>> community >>>>>> * We control which extensions we want to recommend and thus we can >>>> always >>>>>> only take the very good ones and thus control the quality of the >>> initial >>>>>> user experience >>>>>> * We get a mechanism allowing our users to get non-xwiki core dev >>>>>> team-supported extensions into the runtime (thus providing a good user >>>>>> experience) while not bundling them into the default XWiki runtime >>>> flavor. >>>>>> >>>>>> Cons: >>>>>> * The Tour and CKeditor extensions would still incur a higher cost of >>>>>> support/maintenance (but since they’ve already done the code, it’s >>>> marginal >>>>>> for the future and they’ll be able to abandon support for XWiki 6.x >>> soon >>>>>> IMO too - Basically they probably only need to support 2 or 2.5 cycle >>>>>> versions). >>>>>> >>>>>> <similar idea> >>>>>> Ludo mentioned (and I agree with him) that it would be nice to be able >>>> to >>>>>> provide Demo content in the wiki so that users who want to test drive >>>> XWiki >>>>>> can do so with existing content and more clearly see and understand >>> the >>>>>> advantages that XWiki brings. For this, I’d propose to create a Demo >>>>>> Content extension (some AWM app + some blog posts + etc) and once we >>>> have >>>>>> it, recommend it on the Configuration Wizard. >>>>>> </similar idea> >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>> >>>>>>> On 08 Jun 2016, at 17:57, Denis Gervalle <[email protected]> wrote: >>>>>>> >>>>>>> Well, very sorry to drop in so late in this discussion, but it was >>> not >>>>>>> obvious from the thread subject that your were discussing a major >>>>>> subject. >>>>>>> >>>>>>> IMO, moving application that works currently on 6.x to the core, has >>> no >>>>>>> benefit for our users, it just introduce restrictions. It does not >>> have >>>>>> any >>>>>>> benefit for us either, it just require more backports. I do not >>>>>> understand >>>>>>> this move at all for application that are not minimal requirements. I >>>> do >>>>>>> not understand your point Vincent when you say that these >>> applications >>>>>> are >>>>>>> horizontal and obviously part of platform according to your >>> "Executive >>>>>>> summary". >>>>>>> >>>>>>> Regarding the tour application, it is not require at all, it is just >>> a >>>>>> nice >>>>>>> helping tool that we want to ease newcomers, but experienced user >>> will >>>>>>> never need it. It could be exchanged for an alternative, and it is >>>>>> exactly >>>>>>> the same kind of application than the blog that we are moving out. >>>>>>> Regarding the CKEditor, do we consider that a WYSIWYG editor is >>>> required >>>>>>> for a wiki to be a wiki ? IMO, WYSIWYG editor is not a requirement to >>>> use >>>>>>> the platform, it is nice to have, but not required. I have use it >>> very >>>>>>> sparsely until now, and not having it would not have change much for >>>> me. >>>>>>> >>>>>>> So, I currently do not see any benefit of moving these modules to >>>>>> platform, >>>>>>> since these are already well living in contrib. >>>>>>> >>>>>>> Your other point about reducing platform to the minimal runtime would >>>>>> cause >>>>>>> platform to reduce to EM does not really looks like something that >>> will >>>>>>> happen. In theory, you are right, so XWiki would be even less >>> featured >>>>>> then >>>>>>> maven. But, I doubt you could reasonably use such a tools for >>> anything >>>>>>> useful. I doubt XWiki compare to maven. I doubt that horizontal >>> module >>>>>> like >>>>>>> security, logging, model, storage, etc… will ever be considered >>>> optional. >>>>>>> Even a plain text editor is a minimal requirement to starts, else >>> this >>>> is >>>>>>> no more a wiki, and I even wonder what it is ? a tool that brings >>>>>> together >>>>>>> arbitrary java module… looks weird. So no, the minimal runtime is >>>>>>> definitely not just EM. >>>>>>> >>>>>>> So, I really wonder what is the direction we are taking. I will not >>>> stop >>>>>>> you with a veto, but I have the strong feeling these decisions are >>>> wrong. >>>>>>> For the principle of not depending on contrib for our default user >>>>>> flavor, >>>>>>> exchanging the blog app with the tour app, this does not make sens >>> for >>>>>> me, >>>>>>> sorry. >>>>>>> >>>>>>> Thanks for reading. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 8, 2016 at 3:45 PM, Vincent Massol <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>>> FTR I’ve discussed internally with Thomas, Marius and Anca and we >>> all >>>>>>>> agreed that it makes sense to move The Tour app + CKEditor to the >>>>>> platform. >>>>>>>> >>>>>>>> There are various reasons but a very important one is simply the >>>>>> manpower >>>>>>>> that it requires to maintain extensions on lots of XWiki versions >>> and >>>>>>>> currently the active devs on xwiki are not enough to do that. This >>> is >>>>>> the >>>>>>>> reason we dropped this strategy in the past and decided to release >>> the >>>>>>>> whole platform together with the same version. >>>>>>>> >>>>>>>> As part of this the technical debt is being increased since >>> supporting >>>>>>>> several versions and old versions means doing hacks. >>>>>>>> >>>>>>>> If you see another possibility that doesn’t require more work please >>>>>> raise >>>>>>>> it here. >>>>>>>> >>>>>>>> We need to progress and have CKEditor and Tour bundled in >>> 8.2M2(which >>>>>> is >>>>>>>> already started) and thus, barring any negative comments, we’ll >>> start >>>>>> the >>>>>>>> move next week. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> On 07 Jun 2016, at 15:39, Guillaume Delhumeau < >>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>> It also means to move the tour application in that old branches >>> too. >>>>>>>>> >>>>>>>>> 2016-06-07 13:59 GMT+02:00 Vincent Massol <[email protected]>: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 07 Jun 2016, at 10:27, Vincent Massol <[email protected]> >>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On 07 Jun 2016, at 09:37, Guillaume Delhumeau < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Moving Tour Application into platform makes sense to me (it >>>> becomes >>>>>> a >>>>>>>>>>>> critical component and deserves a proper support). >>>>>>>>>>> >>>>>>>>>>> For me, it’s really about the definition of what the XWiki github >>>> org >>>>>>>>>> represents. Right now with the new strategy == “Everything needed >>>> for >>>>>>>> the >>>>>>>>>> default XWiki runtime, a.k.a base/default flavor” (what we’ve been >>>>>>>> calling >>>>>>>>>> XE so far but that we’ll slim down a bit, for example by removing >>>> the >>>>>>>> Blog >>>>>>>>>> app and move it to contrib). >>>>>>>>>>> >>>>>>>>>>> Now we could still decide to have some flavor in contrib and have >>>> the >>>>>>>>>> tour app included in that flavor but not in “the default XWiki >>>>>>>> runtime”. In >>>>>>>>>> practice this would mean promoting this flavor instead of the >>>>>>>> base/default >>>>>>>>>> flavor. The question will arise anyway when we next talk about >>> other >>>>>>>>>> flavors that we may want to have in contrib such a KB flavor, >>>>>> workgroup >>>>>>>>>> flavor, web flavor, etc. >>>>>>>>>>> >>>>>>>>>>>> However, the current >>>>>>>>>>>> application supports XWiki >= 6.4.1. By moving it to platform, >>> we >>>>>> will >>>>>>>>>> only >>>>>>>>>>>> support the last XWiki version. >>>>>>>>>>> >>>>>>>>>>> This is a tough topic indeed. >>>>>>>>>> >>>>>>>>>> Actually in practice we would support not only the last XWiki >>>> version >>>>>>>> but >>>>>>>>>> also the LTS (i.e. 7.4.x + 8.x). If we wanted to support 6.4.x we >>>>>> could >>>>>>>> (we >>>>>>>>>> still have a stable-6.4.x branch ATM that we were supposed to >>>> remove) >>>>>>>> but >>>>>>>>>> it would mean changing our support strategy to support more >>>> branches… >>>>>>>> and >>>>>>>>>> it means supporting the whole platform for 6.4.x, not just one >>>>>>>> extension… >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Vincent >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> For the tour there’s the solution of keeping it in contrib and >>>>>>>>>> introducing a flavor but for CKEditor it’s harder to justify that >>>> it’s >>>>>>>> not >>>>>>>>>> part of the base flavor IMO but maybe it’s possible and we would >>>> offer >>>>>>>> only >>>>>>>>>> the wiki editor in the base flavor. Of course we could modify our >>>>>>>>>> functional tests fwk to support running on various versions of the >>>>>>>>>> dependencies and have CI builds to ensure that an extension works >>>> with >>>>>>>> all >>>>>>>>>> versions but it’s not perfect and it would mean that for the first >>>>>> time >>>>>>>> we >>>>>>>>>> would have code in the xwiki github org that would not use the >>>> latest >>>>>>>>>> APIs/latest JDK features. >>>>>>>>>>> >>>>>>>>>>> The other option is Marius’s, i.e. accept that we hand-pick some >>>>>>>>>> extensions from contrib that we bundle in the base/default flavor >>>> such >>>>>>>> as >>>>>>>>>> the Tour app, CKEditor integration, etc. In this case, we would >>> just >>>>>>>> need >>>>>>>>>> to redefine what “xwiki github org” means. Saying “core component” >>>>>> would >>>>>>>>>> not be enough, it would needs a more precise definition. >>>>>>>>>>> >>>>>>>>>>> Interesting topic ;) >>>>>>>>>>> >>>>>>>>>>> Any other option that we have? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> -Vincent >>>>>>>>>>> >>>>>>>>>>>> 2016-06-06 15:31 GMT+02:00 Vincent Massol <[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On 06 Jun 2016, at 15:24, Marius Dumitru Florea < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jun 6, 2016 at 3:58 PM, Vincent Massol < >>>>>> [email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 06 Jun 2016, at 14:50, Marius Dumitru Florea < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jun 6, 2016 at 3:09 PM, Alexandru Cotiuga < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hello all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As it was decided already, a Homepage Tour have to be >>>>>>>> implemented. >>>>>>>>>>>>>>> However, >>>>>>>>>>>>>>>>> no option regarding the place where the Tour Application >>>> should >>>>>>>> be >>>>>>>>>>>>>>> added as >>>>>>>>>>>>>>>>> dependency was discussed. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There are some possible options: >>>>>>>>>>>>>>>>> 1) XWiki Enterprise >>>>>>>>>>>>>>>>> 2) XWiki Platform Distribution >>>>>>>>>>>>>>>>> 3) XWiki Platform Helper >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 4) Is there any option to have the Tour Application as a >>> part >>>>>> of >>>>>>>>>> the >>>>>>>>>>>>>>> Core ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> What would be the best way to include the Contrib >>>> applications >>>>>> in >>>>>>>>>>>>> XWiki? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On this topic (sorry if I hijack your thread) I was >>> wondering >>>>>> why >>>>>>>>>> don't >>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>> have dependencies from platform/enterprise to contrib. We >>> have >>>>>>>> lots >>>>>>>>>> of >>>>>>>>>>>>>>>> third party dependencies, contrib could be considered as >>> such. >>>>>>>>>>>>> Moreover, >>>>>>>>>>>>>>>> we're in the process of moving non-core (vertical) >>> extensions >>>>>> out >>>>>>>> of >>>>>>>>>>>>>>>> platform to contrib. It would be a pity to move something >>> from >>>>>>>>>> contrib >>>>>>>>>>>>> to >>>>>>>>>>>>>>>> platform and then back to contrib. I have the same issue >>> with >>>>>> the >>>>>>>>>>>>>>> CKEditor >>>>>>>>>>>>>>>> Integration extension. We want CKEditor as the default >>> editor, >>>>>>>>>> bundled >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> the default distribution, but do we need to move it to >>>> platform? >>>>>>>>>> Same >>>>>>>>>>>>> for >>>>>>>>>>>>>>>> the Welcome Tour. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I’d personally not like this for the following reasons: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 1) I like that the XWiki runtime is all released at once with >>>> all >>>>>>>>>>>>>>> extensions making it using the same versions and verified to >>>> work >>>>>>>>>>>>> together. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> XWiki runtime has lots of third party dependencies. Bootstrap, >>>>>> Solr, >>>>>>>>>>>>>> jQuery, just to name a few. I don't see how having the source >>>> code >>>>>>>> in >>>>>>>>>> our >>>>>>>>>>>>>> repo (platform) makes a difference at runtime when the >>>>>>>>>>>>>> integration/functional tests verify they work together. >>>>>>>>>>>>> >>>>>>>>>>>>> Because they don’t! :) Just check any extension in contrib and >>>>>> you’ll >>>>>>>>>> see >>>>>>>>>>>>> their func test (when they have some!) don’t test that they >>> work >>>>>> with >>>>>>>>>> the >>>>>>>>>>>>> latest version of XWiki… >>>>>>>>>>>>> >>>>>>>>>>>>>> 2) Support. The XWiki runtime is supported by the XWiki Core >>> Dev >>>>>>>> Team. >>>>>>>>>>>>>>> Extensions in contrib are not supported by the XWiki Core Dev >>>>>> Team. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> So the FAQ application you moved out of platform is no longer >>>>>>>>>> supported >>>>>>>>>>>>> by >>>>>>>>>>>>>> the XWiki Core Dev Team? >>>>>>>>>>>>> >>>>>>>>>>>>> Correct. >>>>>>>>>>>>> >>>>>>>>>>>>>> The extension page >>>>>>>>>>>>>> >>>>>>>> >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/FAQ+Application >>>>>>>>>>>>>> doesn't reflect this. >>>>>>>>>>>>> >>>>>>>>>>>>> I added my name to the list as a supporter. I’ve kept “XWiki >>> Dev >>>>>>>> Team” >>>>>>>>>>>>> because it's a past authors and it wouldn’t make sense to >>> remove >>>>>> it. >>>>>>>>>> But >>>>>>>>>>>>> yes it’s no longer officially supported by the XWiki Core Dev >>>> Team. >>>>>>>>>>>>> >>>>>>>>>>>>> Note that e.x.o doesn’t say who maintains a given extension, it >>>>>> just >>>>>>>>>> says >>>>>>>>>>>>> who participated to developing it ;) We’re currently missing >>> the >>>>>> info >>>>>>>>>> on >>>>>>>>>>>>> whether the extension is actively supported and by whom. FTR >>>>>>>> Confluence >>>>>>>>>>>>> does this with a “supported” label that you can hover over and >>>>>>>> provides >>>>>>>>>>>>> info. For example: >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> https://marketplace.atlassian.com/plugins/nl.avisi.confluence.plugins.numberedheadings/cloud/overview >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> -Vincent >>>>>>>>>>>>> >>>>>>>>>>>>>> In addition xwiki-contrib is very open and anyone can make >>>>>>>>>> modifications >>>>>>>>>>>>>>> there and quality is thus harder to guarantee. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We defined the xwiki github organization as containing >>>> horizontal >>>>>>>>>>>>> modules, >>>>>>>>>>>>>>> ie modules that can be required for any flavor and both >>>> CKEditor >>>>>>>> and >>>>>>>>>> the >>>>>>>>>>>>>>> Tour Application fit the need. By opposition to vertical >>>> modules >>>>>>>>>> which >>>>>>>>>>>>> make >>>>>>>>>>>>>>> sense only for some use cases (like the Meeting Manager app) >>>> and >>>>>>>> not >>>>>>>>>> by >>>>>>>>>>>>>>> default in XE. We have the option of having flavors in >>> contrib >>>>>> for >>>>>>>>>>>>> those if >>>>>>>>>>>>>>> we want though. For CKEditor it’s not a good thing since we’d >>>>>> like >>>>>>>>>> it by >>>>>>>>>>>>>>> default. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One alternative (which I’m not fond of at all) would be to >>> have >>>>>>>>>> ckeditor >>>>>>>>>>>>>>> as a separate git repo in the xwiki github organization. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> -Vincent >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Marius >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>> Alex > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
