[PROPOSAL] So which Standard flavor dependencies should be optional

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
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 :)).

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
* 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 ?

--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Ecaterina Moraru (Valica)
in theory we should make optional as many as possible, except the ones that
are mandatory :) sounds obvious right? :)

for example, are the macros re-added in XWIKI-14485 really mandatory? Like
the formula, rss, container, etc.

ideally mandatory dependencies should be the ones that should for the base
flavor, that stay at the core of any flavor.

For me is not clear how we will mark the dependencies that are optional,
but that's another topic.

From the list you gave:

On Wed, Jul 5, 2017 at 6:00 PM, Thomas Mortagne <[hidden email]>
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 :)).
>
> 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
>

this should be broken down so we could remove some stuff form there too,
like macro box or message


> * xwiki-platform-office-ui
> * xwiki-platform-invitation-ui
> * xwiki-platform-appwithinminutes-ui
>

this might be core if we consider apps to be core, still on Website you
might not need to create AWM apps


> * xwiki-platform-linkchecker-ui
> * xwiki-platform-sandbox
> * xwiki-platform-sharepage-ui
> * xwiki-platform-distribution-flavor-tour
> * application-templates-ui
>

what about the editors? maybe someone will want only the GWT one? or have
just wiki editor.

It's a hard topic :)

When we uninstall them, will this be reflected in the Active Installs?
Maybe finally we will see some differences between usage of the bundled
extensions.

Anyway, great work Thomas.

Thanks,
Caty


>
> 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 ?
>
> --
> Thomas Mortagne
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator
In reply to this post by Thomas Mortagne
Hi Thomas,

> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]> 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)?

> 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.

> * 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
In reply to this post by Ecaterina Moraru (Valica)
On Wed, Jul 5, 2017 at 5:32 PM, Ecaterina Moraru (Valica)
<[hidden email]> wrote:
> in theory we should make optional as many as possible, except the ones that
> are mandatory :) sounds obvious right? :)
>
> for example, are the macros re-added in XWIKI-14485 really mandatory? Like
> the formula, rss, container, etc.

I'm only talking about the flavor here and nothing else. Those macros
are part of the WAR right now so that's a different subject.

>
> ideally mandatory dependencies should be the ones that should for the base
> flavor, that stay at the core of any flavor.
>
> For me is not clear how we will mark the dependencies that are optional,
> but that's another topic.

Yes and you can find another mail about that :)

>
> From the list you gave:
>
> On Wed, Jul 5, 2017 at 6:00 PM, Thomas Mortagne <[hidden email]>
> 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 :)).
>>
>> 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
>>
>
> this should be broken down so we could remove some stuff form there too,
> like macro box or message
>
>
>> * xwiki-platform-office-ui
>> * xwiki-platform-invitation-ui
>> * xwiki-platform-appwithinminutes-ui
>>
>
> this might be core if we consider apps to be core, still on Website you
> might not need to create AWM apps
>
>
>> * xwiki-platform-linkchecker-ui
>> * xwiki-platform-sandbox
>> * xwiki-platform-sharepage-ui
>> * xwiki-platform-distribution-flavor-tour
>> * application-templates-ui
>>
>
> what about the editors? maybe someone will want only the GWT one? or have
> just wiki editor.

I did not proposed CKEditor because GWT based one is still here only
because we are lazy and we are supposed to ditch it ASAP and I tough
it was not really the kind of thing you would uninstall (anyone can
choose which editor he wants in his profile).

>
> It's a hard topic :)

Not searching a perfect list just yet, just some obviously optional
stuff that don't require heavy refactoring to be made optional.

Others will be made optional on a case by case basic along the way.

>
> When we uninstall them, will this be reflected in the Active Installs?

Yes (at least in term of data), Active Install send installed
extensions with each ping.

> Maybe finally we will see some differences between usage of the bundled
> extensions.
>
> Anyway, great work Thomas.
>
> Thanks,
> Caty
>
>
>>
>> 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 ?
>>
>> --
>> Thomas Mortagne
>>



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
In reply to this post by vmassol
On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:

> Hi Thomas,
>
>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Eduard Moraru
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 <[hidden email]>
wrote:

> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
> > Hi Thomas,
> >
> >> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
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
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

On Fri, Jul 7, 2017 at 12:01 PM, Eduard Moraru <[hidden email]> 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 <[hidden email]>
> wrote:
>
>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>> > Hi Thomas,
>> >
>> >> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Denis Gervalle-2
On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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.
Thanks,
--
Denis Gervalle
SOFTEC sa - CEO

On Fri, Jul 7, 2017 at 12:01 PM, Eduard Moraru <[hidden email]> 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 <[hidden email]>
> wrote:
>
>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>> > Hi Thomas,
>> >
>> >> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator

> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>
> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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).

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 <[hidden email]> 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 <[hidden email]>
>> wrote:
>>
>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>> Hi Thomas,
>>>>
>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Eduard Moraru
In reply to this post by Thomas Mortagne
On Fri, Jul 7, 2017 at 1:16 PM, Thomas Mortagne <[hidden email]>
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
> 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


Are you saying that you have never had to fix a dependency problem in your
Linux distribution caused by some bad commit of a developer or by a
desynchronization of the repository you installed or just updated stuff
from? How you you feel if you were unable to uninstall a dependency from
your system that you know for sure you are not using or, even worse, if you
know it has a sever bug that can fry your system, even if some important
other modules/extensions function very well in practice without it? It
makes no sense to deny this power to an admin by design, except if you have
some technical limitations/problems in implementing it.

The same reasoning applies for the linux "sudo" command. The more control
we give people, the more they will love XWiki, not the other way around.
Sure, they can end up creating a mess, but it's their mess and we should,
at best, warn them about the danger, but that's it. It's basically simple
and advanced mode, but for EM.

Also, extensions can be anything, not only java code. Sometimes it can even
be about a XAR extension or even a webjar (js) that you can really live
without, might want a different (even older) version (because you know it
does not have a certain bug, or some other reason).

More generically, EM now supports adding, removing and upgrading extensions
with dependencies. It should, at some point, be able to perform the same
operations ignoring dependencies (i.e. affecting a single extension) with
the appropriate warnings.

Maybe that helps a bit to explain my reasoning.

Side note/Wishful thinking: Probably as an extension or as part of the
Extension Tweak app, it would be awesome to have a (navigable?) dependency
graph of the installed extensions. Maybe we should have that as a GSoC
project :)

Thanks,
Eduard

>
>
> On Fri, Jul 7, 2017 at 12:01 PM, Eduard Moraru <[hidden email]>
> 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 <
> [hidden email]>
> > wrote:
> >
> >> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]>
> wrote:
> >> > Hi Thomas,
> >> >
> >> >> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
> >> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
In reply to this post by vmassol
On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:

>
>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>
>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 ?

>
> 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 <[hidden email]> 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 <[hidden email]>
>>> wrote:
>>>
>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>> Hi Thomas,
>>>>>
>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
In reply to this post by Eduard Moraru
On Fri, Jul 7, 2017 at 1:56 PM, Eduard Moraru <[hidden email]> wrote:

> On Fri, Jul 7, 2017 at 1:16 PM, Thomas Mortagne <[hidden email]>
> 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
>> 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
>
>
> Are you saying that you have never had to fix a dependency problem in your
> Linux distribution caused by some bad commit of a developer or by a
> desynchronization of the repository you installed or just updated stuff
> from? How you you feel if you were unable to uninstall a dependency from
> your system that you know for sure you are not using or, even worse, if you
> know it has a sever bug that can fry your system, even if some important
> other modules/extensions function very well in practice without it? It
> makes no sense to deny this power to an admin by design, except if you have
> some technical limitations/problems in implementing it.
>
> The same reasoning applies for the linux "sudo" command. The more control
> we give people, the more they will love XWiki, not the other way around.
> Sure, they can end up creating a mess, but it's their mess and we should,
> at best, warn them about the danger, but that's it. It's basically simple
> and advanced mode, but for EM.
>
> Also, extensions can be anything, not only java code. Sometimes it can even
> be about a XAR extension or even a webjar (js) that you can really live
> without, might want a different (even older) version (because you know it
> does not have a certain bug, or some other reason).
>
> More generically, EM now supports adding, removing and upgrading extensions
> with dependencies. It should, at some point, be able to perform the same
> operations ignoring dependencies (i.e. affecting a single extension) with
> the appropriate warnings.

And I'm a lot more confortable if this kind of feature is provided
only when you explicitly make the choice of providing them, A.K.A.
install Extension Tweak extension.

Many actions require admin right so in many cases many users are
granted admin right and nobody ever read the warnings...

>

> Maybe that helps a bit to explain my reasoning.

You said you were fine with making all dependencies optional by
default. This means you could break many extensions without a warning
since being optional there is no reason for EM to complain much about
it. That's the part that does not make any kind of sense to me.

>
> Side note/Wishful thinking: Probably as an extension or as part of the
> Extension Tweak app, it would be awesome to have a (navigable?) dependency
> graph of the installed extensions. Maybe we should have that as a GSoC
> project :)
>
> Thanks,
> Eduard
>
>>
>>
>> On Fri, Jul 7, 2017 at 12:01 PM, Eduard Moraru <[hidden email]>
>> 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 <
>> [hidden email]>
>> > wrote:
>> >
>> >> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]>
>> wrote:
>> >> > Hi Thomas,
>> >> >
>> >> >> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>> >> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator
In reply to this post by Thomas Mortagne
Hi Thomas/All,

> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>
> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>
>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>
>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>> wrote:
>>>>
>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>> Hi Thomas,
>>>>>>
>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator
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).

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?

Thanks
-Vincent

> On 9 Jul 2017, at 13:47, Vincent Massol <[hidden email]> wrote:
>
> Hi Thomas/All,
>
>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>
>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>
>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>
>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>> Hi Thomas,
>>>>>>>
>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator

> On 9 Jul 2017, at 13:55, Vincent Massol <[hidden email]> 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).
>
> 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?

At least the ability to uninstall an extension without uninstalling its dependencies should be a built in feature, do we agree with that?

Thanks
-Vincent

>
> Thanks
> -Vincent
>
>> On 9 Jul 2017, at 13:47, Vincent Massol <[hidden email]> wrote:
>>
>> Hi Thomas/All,
>>
>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>>
>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>>
>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>>
>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>> Hi Thomas,
>>>>>>>>
>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>>> 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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
On Sun, Jul 9, 2017 at 2:00 PM, Vincent Massol <[hidden email]> wrote:
>
>> On 9 Jul 2017, at 13:55, Vincent Massol <[hidden email]> 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).
>>
>> 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 <[hidden email]> wrote:
>>>
>>> Hi Thomas/All,
>>>
>>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>>>
>>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>>>
>>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>>>
>>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>>> Hi Thomas,
>>>>>>>>>
>>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
On Mon, Jul 10, 2017 at 11:09 AM, Thomas Mortagne
<[hidden email]> wrote:
> On Sun, Jul 9, 2017 at 2:00 PM, Vincent Massol <[hidden email]> wrote:
>>
>>> On 9 Jul 2017, at 13:55, Vincent Massol <[hidden email]> 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.

>>>
>>> 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 <[hidden email]> wrote:
>>>>
>>>> Hi Thomas/All,
>>>>
>>>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>>>>
>>>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>
>>>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>>>>
>>>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>>>> Hi Thomas,
>>>>>>>>>>
>>>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>>>>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator
In reply to this post by Thomas Mortagne

> On 10 Jul 2017, at 11:09, Thomas Mortagne <[hidden email]> wrote:
>
> On Sun, Jul 9, 2017 at 2:00 PM, Vincent Massol <[hidden email]> wrote:
>>
>>> On 9 Jul 2017, at 13:55, Vincent Massol <[hidden email]> 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).
>>>
>>> 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.

I know, but I’m taking it as an example. I’m considering the case when a user wants to uninstall an extension not marked as optional.

>
>> 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.

Are you sure that removing it won’t remove the flavor? AFAIR this was the issue before for extensions bundled in the flavor.

Thanks
-Vincent

>
>>
>> Thanks
>> -Vincent
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>>> On 9 Jul 2017, at 13:47, Vincent Massol <[hidden email]> wrote:
>>>>
>>>> Hi Thomas/All,
>>>>
>>>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>>>>
>>>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>
>>>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>>>>
>>>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>>>> Hi Thomas,
>>>>>>>>>>
>>>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>>>>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

vmassol
Administrator
In reply to this post by Thomas Mortagne

> On 10 Jul 2017, at 11:15, Thomas Mortagne <[hidden email]> wrote:
>
> On Mon, Jul 10, 2017 at 11:09 AM, Thomas Mortagne
> <[hidden email]> wrote:
>> On Sun, Jul 9, 2017 at 2:00 PM, Vincent Massol <[hidden email]> wrote:
>>>
>>>> On 9 Jul 2017, at 13:55, Vincent Massol <[hidden email]> 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.

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 <[hidden email]> wrote:
>>>>>
>>>>> Hi Thomas/All,
>>>>>
>>>>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>>>>>
>>>>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>
>>>>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>
>>>>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>>>>>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PROPOSAL] So which Standard flavor dependencies should be optional

Thomas Mortagne
Administrator
On Mon, Jul 10, 2017 at 11:22 AM, Vincent Massol <[hidden email]> wrote:

>
>> On 10 Jul 2017, at 11:15, Thomas Mortagne <[hidden email]> wrote:
>>
>> On Mon, Jul 10, 2017 at 11:09 AM, Thomas Mortagne
>> <[hidden email]> wrote:
>>> On Sun, Jul 9, 2017 at 2:00 PM, Vincent Massol <[hidden email]> wrote:
>>>>
>>>>> On 9 Jul 2017, at 13:55, Vincent Massol <[hidden email]> 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.

>
> 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 <[hidden email]> wrote:
>>>>>>
>>>>>> Hi Thomas/All,
>>>>>>
>>>>>>> On 9 Jul 2017, at 13:28, Thomas Mortagne <[hidden email]> wrote:
>>>>>>>
>>>>>>> On Fri, Jul 7, 2017 at 12:35 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>>
>>>>>>>>> On 7 Jul 2017, at 12:22, Denis Gervalle <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> On Fri, Jul 7, 2017 at 12:16, Thomas Mortagne <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Wed, Jul 5, 2017 at 5:41 PM, Vincent Massol <[hidden email]> wrote:
>>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>>
>>>>>>>>>>>>> On 5 Jul 2017, at 17:00, Thomas Mortagne <[hidden email]>
>>>>>>>>>>> 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
12
Loading...