[xwiki-devs] [Brainstorming] XWiki Flavors
Hi, XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc. Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions. So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom... Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.). After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility. So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Just some ideas. Thanks, Caty [1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
Hi Caty, On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts: * Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that * Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes * Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good. Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings. Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 7, 2013, at 5:38 PM, Eduard Moraru <[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings.
Not sure we're talking about the same thing. There are already extension types (they correspond to the maven <packaging> element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for "POM" or create a new Maven packaging but that's probably unnecessary, supporting POM is enough.
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users).
Yup. Thanks -Vincent
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Feb 7, 2013, at 5:38 PM, Eduard Moraru <[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" < [email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings.
Not sure we're talking about the same thing. There are already extension types (they correspond to the maven <packaging> element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for "POM" or create a new Maven packaging but that's probably unnecessary, supporting POM is enough.
What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. Thanks, Eduard
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users).
Yup.
Thanks -Vincent
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 8, 2013, at 1:39 PM, Eduard Moraru <[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massol <[email protected]> wrote:
On Feb 7, 2013, at 5:38 PM, Eduard Moraru <[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" < [email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings.
Not sure we're talking about the same thing. There are already extension types (they correspond to the maven <packaging> element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for "POM" or create a new Maven packaging but that's probably unnecessary, supporting POM is enough.
What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc.
I think type and category are 2 separate things. For category I was thinking about just using the existing tag feature and making that visible in the EM UI. WDYT? Thanks -Vincent
Thanks, Eduard
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users).
Yup.
Thanks -Vincent
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
On 02/08/2013 02:32 PM, Vincent Massol wrote:
On Feb 8, 2013, at 1:39 PM, Eduard Moraru<[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massol<[email protected]> wrote:
On Feb 7, 2013, at 5:38 PM, Eduard Moraru<[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol<[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)"< [email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies. Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions. Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings. Not sure we're talking about the same thing. There are already extension types (they correspond to the maven<packaging> element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for "POM" or create a new Maven packaging but that's probably unnecessary, supporting POM is enough.
What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. I think type and category are 2 separate things.
For category I was thinking about just using the existing tag feature and making that visible in the EM UI.
Hm, but we have that, no? a beautiful tagcloud on top of the extensions livetable on the main page. The only issue is that tags UI is by default on the bottom of the page, and for extension authors it's not really straightforward to go there and fill in the tags. Maybe if we put a warning in edit mode or something, to tell people to not forget to add tags so that the tags are easier to discover. Anca
WDYT?
Thanks -Vincent
Thanks, Eduard
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Yup.
Thanks -Vincent
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them. Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 8, 2013, at 5:42 PM, Anca Luca <[email protected]> wrote:
On 02/08/2013 02:32 PM, Vincent Massol wrote:
On Feb 8, 2013, at 1:39 PM, Eduard Moraru<[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:47 PM, Vincent Massol<[email protected]> wrote:
On Feb 7, 2013, at 5:38 PM, Eduard Moraru<[email protected]> wrote:
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol<[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)"< [email protected]> wrote:
> Hi, > > XWiki Flavors are a set of predefined extensions having a specific use > case in mind. XWiki Flavors can be considered specializations of XWiki > instances suited for different purposes like public websites, > intranets, content sharing, project management, community status, > business intelligence, etc. > > Scenario: You want to install XWiki. The installer will propose > different 'flavors' and will install automatically all required > extensions. This way you will have a product close to your initial > needs. You can later refine it by installing / uninstalling other > extensions. > > So when I first thought about the process of installing a Flavor I > imagined that I could customize what I wanted from the Flavor and > select just the things I need. Actually for me Flavors were like > categories with subcategories, and more of a classification system, > than a packaging one. > > http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom... > Also another difference in my vision is that I had a Base Package that > contains the common denominator for all Flavors. The Base Package > should contain basic mechanics for managing content and users. > Selecting no flavor will still result in having basic wiki features > (page creation, attachments, history, users, etc.). > > After some discussions with Eduard I understood that Flavors could be > defined as extensions and they could contain just a list of > dependencies on other extensions. The Extension Manager will install > the 'exact' list it gets from the definition without the ability to > exclude some dependencies. Indeed.
> I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] > and for me the conclusion is clear: we will never agree on what > starting features are the best and that will solve everybody's > problems. But that is ok and normal and the strength of XWiki is it's > extensibility. > > So the next idea was to have a Flavor Creator that will allow users to > create their own collections of extensions. This collection should be > then published to extensions.xwiki.org and could appear in the > installer list as suggestions. Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings. Not sure we're talking about the same thing. There are already extension types (they correspond to the maven<packaging> element). Currently AFAIK the EM has implementations for XAR and JAR. We need to add either support for "POM" or create a new Maven packaging but that's probably unnecessary, supporting POM is enough.
What I meant was the ability to specify for each extension that it is an application, a macro, a skin, a flavour, etc. I think type and category are 2 separate things.
For category I was thinking about just using the existing tag feature and making that visible in the EM UI.
Hm, but we have that, no? a beautiful tagcloud on top of the extensions livetable on the main page.
Not in the EM UI. We have it in the Repository app UI. Thanks -Vincent
The only issue is that tags UI is by default on the bottom of the page, and for extension authors it's not really straightforward to go there and fill in the tags. Maybe if we put a warning in edit mode or something, to tell people to not forget to add tags so that the tags are easier to discover.
Anca
WDYT?
Thanks -Vincent
Thanks, Eduard
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users). Yup.
Thanks -Vincent
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
> If Application Within Minutes let's you create your own applications, > the Flavor Creator would let you make packages of extensions for a > specific purpose. This way we strengthen XWiki's extensibility and we > let the users take the power and customize the solutions that are > perfect for them. Sounds good.
Thanks -Vincent
> Just some ideas. > > Thanks, > Caty > > [1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr > [2] [Idea] XWiki Project Development Flavor > http://xwiki.markmail.org/thread/334vzyytfvlppmri > [3] Idea collection minimal xwiki configuration > http://markmail.org/thread/abma4pzuq2ooy6as > [4] [UserStory] Wiki Archetypes > http://xwiki.markmail.org/thread/jp35ackl2puuscjv
Hi devs, I wonder how the "flavor" and "workspace template" concepts would work together ? For example, if I would like to create "community" workspaces would I: A - use a standard XE workspace template, then upgrade it with a "community" flavor extensions ? B - upgrade a standard XE to a "community" flavor, export it as a workspace template and use that I think B is better, because it allows to add some UI to "glue" flavor extensions together the way you like. For example, if I have a MailArchive and a NewsLetter extensions, maybe I would like to add some scripts to generate newsletters for the community, using mailing-lists defined in MailArchive, even if both extensions have no dependencies together. But then, maybe I would just like to add those UI pages directly in my flavor extension, and so make it merely a xar extension with many dependencies... In that case, I would'nt even need a workspace template - only C - choose a flavor when creating my workspace. In that case also, a"flavor" would really be a logical type of extension, and not just a type of packaging of extension. Of course, I could also decide to create UI extensions out of these "glue" pages, with the risk of increasing number of "small & dumb" extensions, and of having to solve potentially complex compatibility issues through long dependency graphs... Only throwing some ideas, but maybe I'm off topic... Br, Jeremie Le 7 févr. 2013 17:39, "Eduard Moraru" <[email protected]> a écrit :
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" < [email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings.
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users).
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Feb 7, 2013, at 7:42 PM, Jeremie BOUSQUET <[email protected]> wrote:
Hi devs,
I wonder how the "flavor" and "workspace template" concepts would work together ? For example, if I would like to create "community" workspaces would I: A - use a standard XE workspace template, then upgrade it with a "community" flavor extensions ? B - upgrade a standard XE to a "community" flavor, export it as a workspace template and use that
In the future when you create a wiki through the Wiki Manager UI you will have the ability to choose a flavor. The same could be done for the Workspace UI.
I think B is better, because it allows to add some UI to "glue" flavor extensions together the way you like. For example, if I have a MailArchive and a NewsLetter extensions, maybe I would like to add some scripts to generate newsletters for the community, using mailing-lists defined in MailArchive, even if both extensions have no dependencies together.
IMO this just means creating a community extension and have the community flavor depends on that extension in addition to all the other extensions making the community flavor. Thanks -Vincent
But then, maybe I would just like to add those UI pages directly in my flavor extension, and so make it merely a xar extension with many dependencies... In that case, I would'nt even need a workspace template - only C - choose a flavor when creating my workspace. In that case also, a"flavor" would really be a logical type of extension, and not just a type of packaging of extension.
Of course, I could also decide to create UI extensions out of these "glue" pages, with the risk of increasing number of "small & dumb" extensions, and of having to solve potentially complex compatibility issues through long dependency graphs...
Only throwing some ideas, but maybe I'm off topic...
Br, Jeremie Le 7 févr. 2013 17:39, "Eduard Moraru" <[email protected]> a écrit :
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" < [email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
I agree with this. IMO, we should bring back the idea of extension types (including this new "flavour" type) and, as you`ve mentioned, add things like ratings.
Also, this should be reflected in the EM UI to allow a user to do browsing (by extension types) and not only searching (which is a bit intimidating to new users).
Thanks, Eduard
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
Hi, Just sharing a bit my ideas iteration process. On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
Last week I was talking about the Flavor Creator:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
My big problem with Flavors is that we are lacking an extensions classification. We had types like applications, skins, colorthemes, etc. but now it's just XARs and JARs. We have a tag cloud, but that is a folksonomy and doesn't have 'standard' categories. When you look at an extension you may not understand it's purpose and usage use case. I've started to categorize our extensions and try to define types of flavors and use cases, but I'm kind of running in circles. But what is clear to me is that we will need some predefined categories and that the Flavor Creator is a must (mainly because we don't have a finite set of extensions and use cases that we are managing). I also thought a bit about the process of integrating gamification in our Extensions Repository (e.x.o) and also a way to encourage users to create Flavors (and also extensions in general). First of all I've revised the wireframe http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... with http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... The main differences is that first you need to select your extensions and then you can decide what the Flavor will be called and what it will be the use case. The Focus (productivity, Collaboration, Development) part is interesting and could reflect your Flavor orientation (but for this we would need the classification system I was talking about). For me for example would be fun to try to create Flavors 100% with one Focus, or to make balanced Flavors, or whatever. Regarding the Flavor creation process I imagined that it could take place locally, but also someone could do it from e.x.o. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/profil... You could receive points for creating, rating, documenting extensions and Flavors. We talked a couple of times about Reputation systems http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Ranking+Applic... and also we had some work integrated in Wiki 3.0 project. Of course we could also think about generic solutions, but my wireframes are related mostly to Flavors and e.x.o. For example, having contributors ranking information we could represent this information on the e.x.o. homepage along with extensions statistics http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/reposi... These are some ideas related more or less to Flavors and how our Extensions Repository could look like and be organized. Thanks, Caty
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Some questions and thoughts about 'flavors': What exactly is a Flavor? First I've said that is just a group of extensions, like a 'bundle'. Another idea in the initial use case was that the Flavor is something installable or 'stand-alone' and you select it when you create a new wiki. Although the 'bundle' version is included in the 'stand-alone' one, the reverse is not valid. I liked very much the idea of a 'bundle' because it provided a way to organize extensions in silos. A simple example, we could bundle our old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature, etc. I've used the Repository Application [5] to define my bundle. * Problem 1: When you create an extension the extension must not be empty (if it's empty you don't get the 'Installable with EM'), it cannot be just a list of dependencies. In the case of 'stand-alone' you should have a custom homepage or other pages, but in a 'bundle' use case you don't need to add something more. I've tricked the Repository App and I've attached a picture with the ColorThemes in the bundle, give it a version, declared the dependencies and it worked. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorT... [Talked with Edy: apparently this is not a problem is just a UI thing for Repository App] * Problem 2: The installation worked very well and now all the dependencies are installed. My problem is that if I want to uninstall this bundle, it will uninstall just the 'bundle' extension and will not touch the dependencies (even if they are not required by any other extension). So maybe they should not be declared as dependencies, but as 'includes' or something. We could test at uninstall if a dependency is not used somewhere else, we can remove it. Without the removal of 'dependencies' my bundle is useless because it cannot be uninstalled. [Talked with Edy: said it's normal, you can manually install extensions and use them and wouldn't not be nice to be deleted, even if they are not declared as dependencies by other extensions] * Problem 3: My bundle contains the OldDefault ColorTheme. When I install the bundle I got a conflict because now we have a new ColorThemes.DefaultColorTheme. I've kept the new version in the conflict resolution phase. The problem is that the conflict decisions are not kept and remembered anywhere. Because my uninstall didn't worked I will need to manually uninstall each ColorTheme. When I will uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme even if is not it (because it doesn't know that I didn't selected it in the Conflict Resolution). What I would like is that if I uninstall an extension or a flavor, the uninstall process would restore the wiki at the 'initial' state. And this example I gave is for ColorThemes.DefaultColorTheme, but Flavors will overwrite the Homepage for example. Uninstalling the Flavor will leave the user without a Homepage, or without a UserPreferences or without groups, etc. [Talked with Edy: said it's problematic :P ] Are any of the problems mentioned something interesting and achievable with EM? Bundles are interesting IMO and they could work for all kinds of grouping, like the Admin Tools, Developer Tools, Content Editing Macros, Social Features Bundle, Importers Bundle, etc. Thanks, Caty [5] http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application On Wed, Feb 13, 2013 at 5:38 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Just sharing a bit my ideas iteration process.
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
Last week I was talking about the Flavor Creator:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
My big problem with Flavors is that we are lacking an extensions classification. We had types like applications, skins, colorthemes, etc. but now it's just XARs and JARs. We have a tag cloud, but that is a folksonomy and doesn't have 'standard' categories. When you look at an extension you may not understand it's purpose and usage use case.
I've started to categorize our extensions and try to define types of flavors and use cases, but I'm kind of running in circles. But what is clear to me is that we will need some predefined categories and that the Flavor Creator is a must (mainly because we don't have a finite set of extensions and use cases that we are managing).
I also thought a bit about the process of integrating gamification in our Extensions Repository (e.x.o) and also a way to encourage users to create Flavors (and also extensions in general).
First of all I've revised the wireframe http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... with http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
The main differences is that first you need to select your extensions and then you can decide what the Flavor will be called and what it will be the use case. The Focus (productivity, Collaboration, Development) part is interesting and could reflect your Flavor orientation (but for this we would need the classification system I was talking about). For me for example would be fun to try to create Flavors 100% with one Focus, or to make balanced Flavors, or whatever.
Regarding the Flavor creation process I imagined that it could take place locally, but also someone could do it from e.x.o. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/profil... You could receive points for creating, rating, documenting extensions and Flavors.
We talked a couple of times about Reputation systems http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Ranking+Applic... and also we had some work integrated in Wiki 3.0 project. Of course we could also think about generic solutions, but my wireframes are related mostly to Flavors and e.x.o.
For example, having contributors ranking information we could represent this information on the e.x.o. homepage along with extensions statistics http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/reposi...
These are some ideas related more or less to Flavors and how our Extensions Repository could look like and be organized.
Thanks, Caty
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Caty, On Tue, Mar 5, 2013 at 1:36 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Some questions and thoughts about 'flavors':
What exactly is a Flavor? First I've said that is just a group of extensions, like a 'bundle'. Another idea in the initial use case was that the Flavor is something installable or 'stand-alone' and you select it when you create a new wiki. Although the 'bundle' version is included in the 'stand-alone' one, the reverse is not valid.
I'm not sure what you mean by 'stand-alone' but any extension is 'stand-alone' in the sense that you can install it on an empty wiki. Of course it has to properly declare its dependencies. if it doesn't work on an empty wiki then most probably it uses something that wasn't declared as a dependency. For me a Flavor is an extension. Just that :). The question is what type of extension. EM currently supports 2 types of extensions: JAR and XAR. So if it were to implement Flavors now they would be XAR extensions. But as you said, you may want to bundle extensions without providing additional wiki pages (e.g. a custom home page). For this we can use empty XAR extensions or we could add support for a new "bundle" extension type in EM.
I liked very much the idea of a 'bundle' because it provided a way to organize extensions in silos. A simple example, we could bundle our old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature, etc. I've used the Repository Application [5] to define my bundle.
* Problem 1: When you create an extension the extension must not be empty (if it's empty you don't get the 'Installable with EM'), it cannot be just a list of dependencies. In the case of 'stand-alone' you should have a custom homepage or other pages, but in a 'bundle' use case you don't need to add something more. I've tricked the Repository App and I've attached a picture with the ColorThemes in the bundle, give it a version, declared the dependencies and it worked. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorT... [Talked with Edy: apparently this is not a problem is just a UI thing for Repository App]
* Problem 2: The installation worked very well and now all the dependencies are installed. My problem is that if I want to uninstall this bundle, it will uninstall just the 'bundle' extension and will not touch the dependencies (even if they are not required by any other extension). So maybe they should not be declared as dependencies, but as 'includes' or something. We could test at uninstall if a dependency is not used somewhere else, we can remove it. Without the removal of 'dependencies' my bundle is useless because it cannot be uninstalled. [Talked with Edy: said it's normal, you can manually install extensions and use them and wouldn't not be nice to be deleted, even if they are not declared as dependencies by other extensions]
Extensions that are not installed explicitly but as a dependency of another extension are marked accordingly in EM. As you can see in http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension+Manager+Appli... the EM knows that this extension is required by another one so it could offer the option to uninstall this extension when uninstalling the extension that brought it as a transitive dependency.
* Problem 3: My bundle contains the OldDefault ColorTheme. When I install the bundle I got a conflict because now we have a new ColorThemes.DefaultColorTheme. I've kept the new version in the conflict resolution phase. The problem is that the conflict decisions are not kept and remembered anywhere. Because my uninstall didn't worked I will need to manually uninstall each ColorTheme. When I will uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme even if is not it (because it doesn't know that I didn't selected it in the Conflict Resolution). What I would like is that if I uninstall an extension or a flavor, the uninstall process would restore the wiki at the 'initial' state. And this example I gave is for ColorThemes.DefaultColorTheme, but Flavors will overwrite the Homepage for example. Uninstalling the Flavor will leave the user without a Homepage, or without a UserPreferences or without groups, etc. [Talked with Edy: said it's problematic :P ]
See http://jira.xwiki.org/browse/XWIKI-8443 . We plan to make the uninstall job interactive. Thanks, Marius
Are any of the problems mentioned something interesting and achievable with EM? Bundles are interesting IMO and they could work for all kinds of grouping, like the Admin Tools, Developer Tools, Content Editing Macros, Social Features Bundle, Importers Bundle, etc.
Thanks, Caty
[5] http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application
On Wed, Feb 13, 2013 at 5:38 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Just sharing a bit my ideas iteration process.
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
Last week I was talking about the Flavor Creator:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
My big problem with Flavors is that we are lacking an extensions classification. We had types like applications, skins, colorthemes, etc. but now it's just XARs and JARs. We have a tag cloud, but that is a folksonomy and doesn't have 'standard' categories. When you look at an extension you may not understand it's purpose and usage use case.
I've started to categorize our extensions and try to define types of flavors and use cases, but I'm kind of running in circles. But what is clear to me is that we will need some predefined categories and that the Flavor Creator is a must (mainly because we don't have a finite set of extensions and use cases that we are managing).
I also thought a bit about the process of integrating gamification in our Extensions Repository (e.x.o) and also a way to encourage users to create Flavors (and also extensions in general).
First of all I've revised the wireframe http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... with http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
The main differences is that first you need to select your extensions and then you can decide what the Flavor will be called and what it will be the use case. The Focus (productivity, Collaboration, Development) part is interesting and could reflect your Flavor orientation (but for this we would need the classification system I was talking about). For me for example would be fun to try to create Flavors 100% with one Focus, or to make balanced Flavors, or whatever.
Regarding the Flavor creation process I imagined that it could take place locally, but also someone could do it from e.x.o. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/profil... You could receive points for creating, rating, documenting extensions and Flavors.
We talked a couple of times about Reputation systems http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Ranking+Applic... and also we had some work integrated in Wiki 3.0 project. Of course we could also think about generic solutions, but my wireframes are related mostly to Flavors and e.x.o.
For example, having contributors ranking information we could represent this information on the e.x.o. homepage along with extensions statistics http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/reposi...
These are some ideas related more or less to Flavors and how our Extensions Repository could look like and be organized.
Thanks, Caty
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Mar 5, 2013 at 12:36 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Some questions and thoughts about 'flavors':
What exactly is a Flavor? First I've said that is just a group of extensions, like a 'bundle'. Another idea in the initial use case was that the Flavor is something installable or 'stand-alone' and you select it when you create a new wiki. Although the 'bundle' version is included in the 'stand-alone' one, the reverse is not valid.
I liked very much the idea of a 'bundle' because it provided a way to organize extensions in silos. A simple example, we could bundle our old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature, etc. I've used the Repository Application [5] to define my bundle.
* Problem 1: When you create an extension the extension must not be empty (if it's empty you don't get the 'Installable with EM'), it cannot be just a list of dependencies. In the case of 'stand-alone' you should have a custom homepage or other pages, but in a 'bundle' use case you don't need to add something more. I've tricked the Repository App and I've attached a picture with the ColorThemes in the bundle, give it a version, declared the dependencies and it worked. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorT... [Talked with Edy: apparently this is not a problem is just a UI thing for Repository App]
It's not just a UI thing but it's not a big issue either, see https://jira.xwiki.org/browse/XWIKI-7260.
* Problem 2: The installation worked very well and now all the dependencies are installed. My problem is that if I want to uninstall this bundle, it will uninstall just the 'bundle' extension and will not touch the dependencies (even if they are not required by any other extension). So maybe they should not be declared as dependencies, but as 'includes' or something. We could test at uninstall if a dependency is not used somewhere else, we can remove it. Without the removal of 'dependencies' my bundle is useless because it cannot be uninstalled. [Talked with Edy: said it's normal, you can manually install extensions and use them and wouldn't not be nice to be deleted, even if they are not declared as dependencies by other extensions]
Yes it should be a new kind of dependency in Extension Manager (probably just a property in a dependency). On Maven side we could reuse <optional> dependency property probably.
* Problem 3: My bundle contains the OldDefault ColorTheme. When I install the bundle I got a conflict because now we have a new ColorThemes.DefaultColorTheme. I've kept the new version in the conflict resolution phase. The problem is that the conflict decisions are not kept and remembered anywhere. Because my uninstall didn't worked I will need to manually uninstall each ColorTheme. When I will uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme even if is not it (because it doesn't know that I didn't selected it in the Conflict Resolution). What I would like is that if I uninstall an extension or a flavor, the uninstall process would restore the wiki at the 'initial' state. And this example I gave is for ColorThemes.DefaultColorTheme, but Flavors will overwrite the Homepage for example. Uninstalling the Flavor will leave the user without a Homepage, or without a UserPreferences or without groups, etc. [Talked with Edy: said it's problematic :P ]
Yea "problematic" is an euphemism. What is planned shortly is http://jira.xwiki.org/browse/XWIKI-8443 (in your use case you would get a conflict about ColorThemes.DefaultColorTheme page when uninstalling because it's part of another extension that is not i the uninstall plan).
Are any of the problems mentioned something interesting and achievable with EM? Bundles are interesting IMO and they could work for all kinds of grouping, like the Admin Tools, Developer Tools, Content Editing Macros, Social Features Bundle, Importers Bundle, etc.
Bundles are how flavors among other things were planned to be implemented since a long time. General notes: what is in Extension Manager right now is what we managed to do in the time frame, there is plenty of ideas and plans for it but that require someone to do it ;)
Thanks, Caty
[5] http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application
On Wed, Feb 13, 2013 at 5:38 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Just sharing a bit my ideas iteration process.
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
Last week I was talking about the Flavor Creator:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
My big problem with Flavors is that we are lacking an extensions classification. We had types like applications, skins, colorthemes, etc. but now it's just XARs and JARs. We have a tag cloud, but that is a folksonomy and doesn't have 'standard' categories. When you look at an extension you may not understand it's purpose and usage use case.
I've started to categorize our extensions and try to define types of flavors and use cases, but I'm kind of running in circles. But what is clear to me is that we will need some predefined categories and that the Flavor Creator is a must (mainly because we don't have a finite set of extensions and use cases that we are managing).
I also thought a bit about the process of integrating gamification in our Extensions Repository (e.x.o) and also a way to encourage users to create Flavors (and also extensions in general).
First of all I've revised the wireframe http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... with http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
The main differences is that first you need to select your extensions and then you can decide what the Flavor will be called and what it will be the use case. The Focus (productivity, Collaboration, Development) part is interesting and could reflect your Flavor orientation (but for this we would need the classification system I was talking about). For me for example would be fun to try to create Flavors 100% with one Focus, or to make balanced Flavors, or whatever.
Regarding the Flavor creation process I imagined that it could take place locally, but also someone could do it from e.x.o. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/profil... You could receive points for creating, rating, documenting extensions and Flavors.
We talked a couple of times about Reputation systems http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Ranking+Applic... and also we had some work integrated in Wiki 3.0 project. Of course we could also think about generic solutions, but my wireframes are related mostly to Flavors and e.x.o.
For example, having contributors ranking information we could represent this information on the e.x.o. homepage along with extensions statistics http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/reposi...
These are some ideas related more or less to Flavors and how our Extensions Repository could look like and be organized.
Thanks, Caty
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, Mar 6, 2013 at 10:33 AM, Thomas Mortagne <[email protected]> wrote:
On Tue, Mar 5, 2013 at 12:36 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Some questions and thoughts about 'flavors':
What exactly is a Flavor? First I've said that is just a group of extensions, like a 'bundle'. Another idea in the initial use case was that the Flavor is something installable or 'stand-alone' and you select it when you create a new wiki. Although the 'bundle' version is included in the 'stand-alone' one, the reverse is not valid.
I liked very much the idea of a 'bundle' because it provided a way to organize extensions in silos. A simple example, we could bundle our old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature, etc. I've used the Repository Application [5] to define my bundle.
* Problem 1: When you create an extension the extension must not be empty (if it's empty you don't get the 'Installable with EM'), it cannot be just a list of dependencies. In the case of 'stand-alone' you should have a custom homepage or other pages, but in a 'bundle' use case you don't need to add something more. I've tricked the Repository App and I've attached a picture with the ColorThemes in the bundle, give it a version, declared the dependencies and it worked. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorT... [Talked with Edy: apparently this is not a problem is just a UI thing for Repository App]
It's not just a UI thing but it's not a big issue either, see https://jira.xwiki.org/browse/XWIKI-7260.
* Problem 2: The installation worked very well and now all the dependencies are installed. My problem is that if I want to uninstall this bundle, it will uninstall just the 'bundle' extension and will not touch the dependencies (even if they are not required by any other extension). So maybe they should not be declared as dependencies, but as 'includes' or something. We could test at uninstall if a dependency is not used somewhere else, we can remove it. Without the removal of 'dependencies' my bundle is useless because it cannot be uninstalled. [Talked with Edy: said it's normal, you can manually install extensions and use them and wouldn't not be nice to be deleted, even if they are not declared as dependencies by other extensions]
Yes it should be a new kind of dependency in Extension Manager (probably just a property in a dependency). On Maven side we could reuse <optional> dependency property probably.
* Problem 3: My bundle contains the OldDefault ColorTheme. When I install the bundle I got a conflict because now we have a new ColorThemes.DefaultColorTheme. I've kept the new version in the conflict resolution phase. The problem is that the conflict decisions are not kept and remembered anywhere. Because my uninstall didn't worked I will need to manually uninstall each ColorTheme. When I will uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme even if is not it (because it doesn't know that I didn't selected it in the Conflict Resolution). What I would like is that if I uninstall an extension or a flavor, the uninstall process would restore the wiki at the 'initial' state. And this example I gave is for ColorThemes.DefaultColorTheme, but Flavors will overwrite the Homepage for example. Uninstalling the Flavor will leave the user without a Homepage, or without a UserPreferences or without groups, etc. [Talked with Edy: said it's problematic :P ]
Yea "problematic" is an euphemism. What is planned shortly is http://jira.xwiki.org/browse/XWIKI-8443 (in your use case you would get a conflict about ColorThemes.DefaultColorTheme page when uninstalling because it's part of another extension that is not i the uninstall plan).
Are any of the problems mentioned something interesting and achievable with EM? Bundles are interesting IMO and they could work for all kinds of grouping, like the Admin Tools, Developer Tools, Content Editing Macros, Social Features Bundle, Importers Bundle, etc.
Bundles are how flavors among other things were planned to be implemented since a long time.
General notes: what is in Extension Manager right now is what we managed to do in the time frame, there is plenty of ideas and plans for it but that require someone to do it ;)
I know there are things about EM that I don't know about and I am writing these mails in case there are use cases that you didn't thought about :) (maybe) Thank you for your answers, Caty
Thanks, Caty
[5] http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application
On Wed, Feb 13, 2013 at 5:38 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Just sharing a bit my ideas iteration process.
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
Last week I was talking about the Flavor Creator:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
My big problem with Flavors is that we are lacking an extensions classification. We had types like applications, skins, colorthemes, etc. but now it's just XARs and JARs. We have a tag cloud, but that is a folksonomy and doesn't have 'standard' categories. When you look at an extension you may not understand it's purpose and usage use case.
I've started to categorize our extensions and try to define types of flavors and use cases, but I'm kind of running in circles. But what is clear to me is that we will need some predefined categories and that the Flavor Creator is a must (mainly because we don't have a finite set of extensions and use cases that we are managing).
I also thought a bit about the process of integrating gamification in our Extensions Repository (e.x.o) and also a way to encourage users to create Flavors (and also extensions in general).
First of all I've revised the wireframe http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... with http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
The main differences is that first you need to select your extensions and then you can decide what the Flavor will be called and what it will be the use case. The Focus (productivity, Collaboration, Development) part is interesting and could reflect your Flavor orientation (but for this we would need the classification system I was talking about). For me for example would be fun to try to create Flavors 100% with one Focus, or to make balanced Flavors, or whatever.
Regarding the Flavor creation process I imagined that it could take place locally, but also someone could do it from e.x.o. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/profil... You could receive points for creating, rating, documenting extensions and Flavors.
We talked a couple of times about Reputation systems http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Ranking+Applic... and also we had some work integrated in Wiki 3.0 project. Of course we could also think about generic solutions, but my wireframes are related mostly to Flavors and e.x.o.
For example, having contributors ranking information we could represent this information on the e.x.o. homepage along with extensions statistics http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/reposi...
These are some ideas related more or less to Flavors and how our Extensions Repository could look like and be organized.
Thanks, Caty
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Mar 6, 2013 at 11:55 AM, Ecaterina Moraru (Valica) <[email protected]> wrote:
On Wed, Mar 6, 2013 at 10:33 AM, Thomas Mortagne <[email protected]> wrote:
On Tue, Mar 5, 2013 at 12:36 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Some questions and thoughts about 'flavors':
What exactly is a Flavor? First I've said that is just a group of extensions, like a 'bundle'. Another idea in the initial use case was that the Flavor is something installable or 'stand-alone' and you select it when you create a new wiki. Although the 'bundle' version is included in the 'stand-alone' one, the reverse is not valid.
I liked very much the idea of a 'bundle' because it provided a way to organize extensions in silos. A simple example, we could bundle our old ColorThemes in a 'Default ColorThemes before 3.4 Bundle'. This bundle has 6 dependencies to ColorThemes: OldDefault, Bordo, Nature, etc. I've used the Repository Application [5] to define my bundle.
* Problem 1: When you create an extension the extension must not be empty (if it's empty you don't get the 'Installable with EM'), it cannot be just a list of dependencies. In the case of 'stand-alone' you should have a custom homepage or other pages, but in a 'bundle' use case you don't need to add something more. I've tricked the Repository App and I've attached a picture with the ColorThemes in the bundle, give it a version, declared the dependencies and it worked. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/ColorT... [Talked with Edy: apparently this is not a problem is just a UI thing for Repository App]
It's not just a UI thing but it's not a big issue either, see https://jira.xwiki.org/browse/XWIKI-7260.
* Problem 2: The installation worked very well and now all the dependencies are installed. My problem is that if I want to uninstall this bundle, it will uninstall just the 'bundle' extension and will not touch the dependencies (even if they are not required by any other extension). So maybe they should not be declared as dependencies, but as 'includes' or something. We could test at uninstall if a dependency is not used somewhere else, we can remove it. Without the removal of 'dependencies' my bundle is useless because it cannot be uninstalled. [Talked with Edy: said it's normal, you can manually install extensions and use them and wouldn't not be nice to be deleted, even if they are not declared as dependencies by other extensions]
Yes it should be a new kind of dependency in Extension Manager (probably just a property in a dependency). On Maven side we could reuse <optional> dependency property probably.
* Problem 3: My bundle contains the OldDefault ColorTheme. When I install the bundle I got a conflict because now we have a new ColorThemes.DefaultColorTheme. I've kept the new version in the conflict resolution phase. The problem is that the conflict decisions are not kept and remembered anywhere. Because my uninstall didn't worked I will need to manually uninstall each ColorTheme. When I will uninstall the OldDefault it will delete ColorThemes.DefaultColorTheme even if is not it (because it doesn't know that I didn't selected it in the Conflict Resolution). What I would like is that if I uninstall an extension or a flavor, the uninstall process would restore the wiki at the 'initial' state. And this example I gave is for ColorThemes.DefaultColorTheme, but Flavors will overwrite the Homepage for example. Uninstalling the Flavor will leave the user without a Homepage, or without a UserPreferences or without groups, etc. [Talked with Edy: said it's problematic :P ]
Yea "problematic" is an euphemism. What is planned shortly is http://jira.xwiki.org/browse/XWIKI-8443 (in your use case you would get a conflict about ColorThemes.DefaultColorTheme page when uninstalling because it's part of another extension that is not i the uninstall plan).
Are any of the problems mentioned something interesting and achievable with EM? Bundles are interesting IMO and they could work for all kinds of grouping, like the Admin Tools, Developer Tools, Content Editing Macros, Social Features Bundle, Importers Bundle, etc.
Bundles are how flavors among other things were planned to be implemented since a long time.
General notes: what is in Extension Manager right now is what we managed to do in the time frame, there is plenty of ideas and plans for it but that require someone to do it ;)
I know there are things about EM that I don't know about and I am writing these mails in case there are use cases that you didn't thought about :) (maybe)
Note that there is http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager to gather future ideas about extensions manager, would be great if you could report here all that cross your mind. When something become pretty sure we create jira issue for it.
Thank you for your answers, Caty
Thanks, Caty
[5] http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository+Application
On Wed, Feb 13, 2013 at 5:38 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:
Hi,
Just sharing a bit my ideas iteration process.
On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <[email protected]> wrote:
Hi Caty,
On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" <[email protected]> wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
Indeed.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
Some thoughts:
* Yes, the idea is that anyone can contribute a flavor on xwiki.org, since it's an extension like any other (it would just have a new type, called "flavor" since we don't have this ATM). The DW will list all flavors it can find from e.x.o. This is where we need some ways to bring the best flavors to the top. My idea was to add ratings to the Repository app for that
* Also, in the DW the user should be allowed to not install any flavor so that he can then install extensions one by one if he so wishes
* Re the base package there's no need to have one since extensions declare their require dependencies
Last week I was talking about the Flavor Creator:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
My big problem with Flavors is that we are lacking an extensions classification. We had types like applications, skins, colorthemes, etc. but now it's just XARs and JARs. We have a tag cloud, but that is a folksonomy and doesn't have 'standard' categories. When you look at an extension you may not understand it's purpose and usage use case.
I've started to categorize our extensions and try to define types of flavors and use cases, but I'm kind of running in circles. But what is clear to me is that we will need some predefined categories and that the Flavor Creator is a must (mainly because we don't have a finite set of extensions and use cases that we are managing).
I also thought a bit about the process of integrating gamification in our Extensions Repository (e.x.o) and also a way to encourage users to create Flavors (and also extensions in general).
First of all I've revised the wireframe http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor... with http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
The main differences is that first you need to select your extensions and then you can decide what the Flavor will be called and what it will be the use case. The Focus (productivity, Collaboration, Development) part is interesting and could reflect your Flavor orientation (but for this we would need the classification system I was talking about). For me for example would be fun to try to create Flavors 100% with one Focus, or to make balanced Flavors, or whatever.
Regarding the Flavor creation process I imagined that it could take place locally, but also someone could do it from e.x.o. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/profil... You could receive points for creating, rating, documenting extensions and Flavors.
We talked a couple of times about Reputation systems http://extensions.xwiki.org/xwiki/bin/view/Extension/Activity+Ranking+Applic... and also we had some work integrated in Wiki 3.0 project. Of course we could also think about generic solutions, but my wireframes are related mostly to Flavors and e.x.o.
For example, having contributors ranking information we could represent this information on the e.x.o. homepage along with extensions statistics http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/reposi...
These are some ideas related more or less to Flavors and how our Extensions Repository could look like and be organized.
Thanks, Caty
Sounds good.
Thanks -Vincent
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, What I wanted to add to this is that, basically, a Flavour could also be viewed as a regular extension that specifies dependencies to other extensions. The difference between this an other extensions is that other extensions generally have metadata (including description and dependencies) and content (wiki pages), while flavours could come only with the metadata. Building on this, I would rather see this as not only a Flavour creator, but, more generally, as an extension metadata editor and, perhaps, publisher, which could be nicely coupled with AWM (as Caty already mentioned) to offer a complete toolchain of creating and publishing extensions to an XWiki extension repository. Thanks, Eduard On Thu, Feb 7, 2013 at 6:08 PM, Ecaterina Moraru (Valica) <[email protected]
wrote:
Hi,
XWiki Flavors are a set of predefined extensions having a specific use case in mind. XWiki Flavors can be considered specializations of XWiki instances suited for different purposes like public websites, intranets, content sharing, project management, community status, business intelligence, etc.
Scenario: You want to install XWiki. The installer will propose different 'flavors' and will install automatically all required extensions. This way you will have a product close to your initial needs. You can later refine it by installing / uninstalling other extensions.
So when I first thought about the process of installing a Flavor I imagined that I could customize what I wanted from the Flavor and select just the things I need. Actually for me Flavors were like categories with subcategories, and more of a classification system, than a packaging one.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/custom...
Also another difference in my vision is that I had a Base Package that contains the common denominator for all Flavors. The Base Package should contain basic mechanics for managing content and users. Selecting no flavor will still result in having basic wiki features (page creation, attachments, history, users, etc.).
After some discussions with Eduard I understood that Flavors could be defined as extensions and they could contain just a list of dependencies on other extensions. The Extension Manager will install the 'exact' list it gets from the definition without the ability to exclude some dependencies.
I've watched the 'recent' mails about XWiki Flavors [1] [2] [3] [4] and for me the conclusion is clear: we will never agree on what starting features are the best and that will solve everybody's problems. But that is ok and normal and the strength of XWiki is it's extensibility.
So the next idea was to have a Flavor Creator that will allow users to create their own collections of extensions. This collection should be then published to extensions.xwiki.org and could appear in the installer list as suggestions.
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavor...
If Application Within Minutes let's you create your own applications, the Flavor Creator would let you make packages of extensions for a specific purpose. This way we strengthen XWiki's extensibility and we let the users take the power and customize the solutions that are perfect for them.
Just some ideas.
Thanks, Caty
[1] [Idea]"Community" flavor http://xwiki.markmail.org/thread/2e3fdm3hfuh54vpr [2] [Idea] XWiki Project Development Flavor http://xwiki.markmail.org/thread/334vzyytfvlppmri [3] Idea collection minimal xwiki configuration http://markmail.org/thread/abma4pzuq2ooy6as [4] [UserStory] Wiki Archetypes http://xwiki.markmail.org/thread/jp35ackl2puuscjv _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (7)
-
Anca Luca -
Ecaterina Moraru (Valica) -
Eduard Moraru -
Jeremie BOUSQUET -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol