On Mon, Jul 10, 2017 at 11:26 AM, Vincent Massol <[email protected]> wrote: > >> On 10 Jul 2017, at 11:24, Thomas Mortagne <[email protected]> wrote: >> >> On Mon, Jul 10, 2017 at 11:22 AM, Vincent Massol <[email protected]> wrote: >>> >>>> On 10 Jul 2017, at 11:15, Thomas Mortagne <[email protected]> >>>> wrote: >>>> >>>> On Mon, Jul 10, 2017 at 11:09 AM, Thomas Mortagne >>>> <[email protected]> wrote: >>>>> On Sun, Jul 9, 2017 at 2:00 PM, Vincent Massol <[email protected]> wrote: >>>>>> >>>>>>> On 9 Jul 2017, at 13:55, Vincent Massol <[email protected]> wrote: >>>>>>> >>>>>>> Note to be clear: I prefer having the feature in the Extension Tweak >>>>>>> Extension that not having it at all ;) But I also prefer having it by >>>>>>> default in EM as an advanced. The main use case/need I see is >>>>>>> installing/uninstalling XAR applications and those are not really >>>>>>> dangerous in general. >>>>>>> >>>> >>>>>>> I also agree with you that we need to try preserving the stability of >>>>>>> XWiki as much as possible. We could even make some checks and only >>>>>>> allow some use cases (the XAR ones). >>>> >>>> There is no real reason for removing a XAR to be always safe. XAR >>>> could contain classes or tools you require, just think about what >>>> removing xwiki-platform-appwithinminutes-ui or >>>> xwiki-platform-livetable-ui would do to most of the applications. >>> >>> Ok, indeed if we don’t allow uninstalling core extensions (and that’s a >>> good thing :)) then it’s the same whether it’s jars or xars. And >>> uninstalling those extensions can break your wiki behavior or wiki pages >>> but they shouldn't break the wiki itself, which is good. >> >> How are those core extension ? There is no technical difference >> between those and any other XAR extension from EM point of view right >> now. > > For me, core extensions = the ones in WEB-INF/lib.
For me too. How do yo put a XAR in WEB-INF/lib ? I don't think you read properly what extensions I was talking about. > > In EM UI, there’s a “Core Extensions” filter AFAIR. > > Thanks > -Vincent > >> >>> Thanks >>> -Vincent >>> >>>> >>>>>>> >>>>>>> Also there are some uses case for which I don’t understand why they’re >>>>>>> dangerous. Why would it be dangerous for example to uninstall the Tour >>>>>>> Application? >>>>>> >>>>> >>>>> Again you are mixing different things here. The Tour application >>>>> should be listed as optional in the default flavor so there is no need >>>>> to force anything. >>>>> >>>>>> At least the ability to uninstall an extension without uninstalling its >>>>>> dependencies should be a built in feature, do we agree with that? >>>>> >>>>> Are you sure that's what you want to ask ? That's how it always worked. >>>>> >>>>>> >>>>>> Thanks >>>>>> -Vincent >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> -Vincent >>>>>>> >>>>>>>> On 9 Jul 2017, at 13:47, Vincent Massol <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Thomas/All, >>>>>>>> >>>>>>>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> I really don't understand how you end up with this reasoning. >>>>>>>>>>> >>>>>>>>>>> The only one that knows if a dependency is optional is the developer >>>>>>>>>>> I agree. >>>>>>>>>>> of the extension so what is a workaround here is the huge mess >>>>>>>>>>> generator you are proposing. >>>>>>>>>>> >>>>>>>>>>> As I already said 99% of our dependencies are really not optional, >>>>>>>>>>> in >>>>>>>>>>> practice only a few flavor dependencies are and one or two other use >>>>>>>>>>> cases. >>>>>>>>>>> >>>>>>>>>>> There is two different subjects that get mixed up here: >>>>>>>>>>> * clearly state in an extension what is absolutely required to work >>>>>>>>>>> and what is a nice to have, this is standard stuff and this is what >>>>>>>>>>> we >>>>>>>>>>> are talking about here >>>>>>>>>>> * hack your way in the extension index to remove an extension >>>>>>>>>>> without >>>>>>>>>>> removing the extension claiming to require that, this is at best >>>>>>>>>>> something for >>>>>>>>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Tweak >>>>>>>>>>> Or the UI of EM can provide a big red warning based dialog to allow >>>>>>>>>>> admin to overwrite the default behaviour with a message about the >>>>>>>>>>> risk. Just best of both world proposal :), but I don’t know how >>>>>>>>>>> complex it could be. I am also fine with a Extension Tweak solution. >>>>>>>>>> >>>>>>>>>> I agree and this is exactly what I was hinting at in my past reply >>>>>>>>>> with: >>>>>>>>>> >>>>>>>>>> " What if I want to uninstall an extension which is NOT marked as >>>>>>>>>> optional (ie force uninstall at your own risks)?” >>>>>>>>>> >>>>>>>>>> I disagree that Extension Tweak is enough. This is quite technical >>>>>>>>>> and not installed by default. I’d really prefer that this be a >>>>>>>>>> feature of EM (force install and force uninstall). >>>>>>>>> >>>>>>>>> So you are saying that going against the recommendations expressed by >>>>>>>>> an extension author is less technical than installing an extension >>>>>>>>> dedicated to dangerous manipulations ? >>>>>>>> >>>>>>>> When it’s needed the user will not find it (very low discoverability) >>>>>>>> and installing an unsupported extension (by the xwiki core dev team) >>>>>>>> is also not a great idea for doing anything that can be dangerous. >>>>>>>> >>>>>>>> It would really be awkward to me that you’d need to install an >>>>>>>> extension for being allowing to force install/uninstall an extension. >>>>>>>> That sounds too small and weird a use case. This just looks like an >>>>>>>> Advanced Option that should be there by default in EM. And here the >>>>>>>> user doesn’t care about all the other stuff that the Extension Tweak >>>>>>>> Extension can do. Personally I dislike this Extension Tweak Extension >>>>>>>> and I see it as a temporary bandaid till we get its features inside >>>>>>>> XWiki. I see it in a similar way as I see a *Util class in Java (which >>>>>>>> is bad design); it means that the features are missing from the >>>>>>>> default. >>>>>>>> >>>>>>>> Another good example is the ability to reinstall a SNAPSHOT extension. >>>>>>>> Right now you have to use the Extension Tweak extension (to clear the >>>>>>>> extension cache) in all wiki where you want to do that and since you >>>>>>>> do that in dev mode and that in dev mode you keep having different >>>>>>>> xwiki instances, it just doesn’t work and the extra work is too >>>>>>>> overwhelming. So similarly we should allow force reinstall of an >>>>>>>> extension, even for snapshots, and not need the Extension Tweak >>>>>>>> extension for that. At the very least, the ability to clear the cache >>>>>>>> should be built in, in the Admin UI for EM. >>>>>>>> >>>>>>>> I’m not saying that Extensions that are not useful in general, just >>>>>>>> that there are some admin features that needs to be built in, to make >>>>>>>> life simpler. And what’s in Extension Tweaks are good candidates. >>>>>>>> >>>>>>>> Thanks >>>>>>>> -Vincent >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note that the "Force install” use case is for example for forcing to >>>>>>>>>> install a XAR extension even if the version requirements are not >>>>>>>>>> honored. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> -Vincent >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> -- >>>>>>>>>>> Denis Gervalle >>>>>>>>>>> SOFTEC sa - CEO >>>>>>>>>>> >>>>>>>>>>> On Fri, Jul 7, 2017 at 12:01 PM, Eduard Moraru >>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> It`s very nice to hear we are progressing on this topic, but I`m >>>>>>>>>>>> not very >>>>>>>>>>>> fond of the current solution. Marking dependencies as optional >>>>>>>>>>>> still puts >>>>>>>>>>>> the responsibility on the developer to actually do that and makes >>>>>>>>>>>> the admin >>>>>>>>>>>> dependent on the developer's choice and discipline. Feels more >>>>>>>>>>>> like a >>>>>>>>>>>> workaround that we will end up having to support. >>>>>>>>>>>> >>>>>>>>>>>> Working for building whitelists is a tedious process and we will >>>>>>>>>>>> surely >>>>>>>>>>>> miss things, and this is only about things that we control in the >>>>>>>>>>>> standard >>>>>>>>>>>> flavor. What about extensions and their dependencies? >>>>>>>>>>>> >>>>>>>>>>>> Sure, as Caty suggests, one option is to make everything optional >>>>>>>>>>>> by >>>>>>>>>>>> default and only have to explicitly specify if a dependency is >>>>>>>>>>>> mandatory. >>>>>>>>>>>> >>>>>>>>>>>> Hoping we can get to a point where all the power is to the admin >>>>>>>>>>>> running >>>>>>>>>>>> XWiki, not the developer. >>>>>>>>>>>> >>>>>>>>>>>> Getting past the above "critique", it's still very nice to hear >>>>>>>>>>>> that we >>>>>>>>>>>> will now have one solution to this old problem. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Eduard >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Jul 5, 2017 at 6:43 PM, Thomas Mortagne >>>>>>>>>>>> <[email protected]> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol >>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>> Hi Thomas, >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne >>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I just implemented https://jira.xwiki.org/browse/XCOMMONS-1229 >>>>>>>>>>>>>>> which >>>>>>>>>>>>>>> allows to indicate that a dependency will be installed by >>>>>>>>>>>>>>> default but >>>>>>>>>>>>>>> does not have a string dependency link with the extension, >>>>>>>>>>>>>>> meaning >>>>>>>>>>>>>>> that uninstalling it won't impact the backward dependencies (so >>>>>>>>>>>>>>> they >>>>>>>>>>>>>>> are not really backward dependencies in that case :)). >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is very nice. What if I want to uninstall an extension >>>>>>>>>>>>>> which is NOT >>>>>>>>>>>>> marked as optional (ie force uninstall at your own risks)? >>>>>>>>>>>>> >>>>>>>>>>>>> If it's not optional then... it's not optional and require to >>>>>>>>>>>>> uninstall backward dependency. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Now we need to decide what exactly is optional in Standard >>>>>>>>>>>>>>> flavor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Here are some ideas: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> * application-help-center >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * xwiki-platform-menu-ui >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * xwiki-platform-wiki-ui-mainwiki >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * xwiki-platform-office-ui >>>>>>>>>>>>>>> * xwiki-platform-invitation-ui >>>>>>>>>>>>>>> * xwiki-platform-appwithinminutes-ui >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think it needs some refactoring first since the pages it >>>>>>>>>>>>>> generates >>>>>>>>>>>>> still need some pages from AWM. >>>>>>>>>>>>> >>>>>>>>>>>>> Actually I tough about that and IMO if an extension has AWM pages >>>>>>>>>>>>> it >>>>>>>>>>>>> should have a non optional dependency on AWM (i.e. it would be >>>>>>>>>>>>> optional from flavor point of view but non optional from other >>>>>>>>>>>>> extension point of view). >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * xwiki-platform-linkchecker-ui >>>>>>>>>>>>>>> * xwiki-platform-sandbox >>>>>>>>>>>>>> >>>>>>>>>>>>>>> * xwiki-platform-sharepage-ui >>>>>>>>>>>>>>> * xwiki-platform-distribution-flavor-tour >>>>>>>>>>>>>>> * application-templates-ui >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I did not actually tried to uninstall those so it's possible >>>>>>>>>>>>>>> it's not >>>>>>>>>>>>>>> a good idea to uninstall some of them right now (hardcoded use >>>>>>>>>>>>>>> somewhere maybe). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WDYT ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> The list sounds good to start with (we need to test remove them >>>>>>>>>>>>>> first >>>>>>>>>>>>> ofc). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> -Vincent >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>> >>>> >>>> >>>> -- >>>> Thomas Mortagne >>> >> >> >> >> -- >> Thomas Mortagne > -- Thomas Mortagne
