On Wed, Mar 6, 2013 at 10:33 AM, Thomas Mortagne <thomas.morta...@xwiki.com> wrote: > On Tue, Mar 5, 2013 at 12:36 PM, Ecaterina Moraru (Valica) > <vali...@gmail.com> 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/ColorThemesBundle.png >> [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) >> <vali...@gmail.com> wrote: >>> Hi, >>> >>> Just sharing a bit my ideas iteration process. >>> >>> On Thu, Feb 7, 2013 at 6:31 PM, Vincent Massol <vinc...@massol.net> wrote: >>>> Hi Caty, >>>> >>>> On Feb 7, 2013, at 5:08 PM, "Ecaterina Moraru (Valica)" >>>> <vali...@gmail.com> 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/customizedInstall.png >>>>> >>>>> 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/flavorCreator.png >>>>> >>>>> 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/flavorCreator.png >>> with >>> http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Flavours/flavorCreatorV2.png >>> >>> 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/profileReputation.png >>> 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+Application >>> 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/repositoryHomepage.png >>> >>> 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 >>>> devs@xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> devs@xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
