Hi, I'm not sure I know what are the differences between 1-4.
I assume: 1) needs to be defined in the .pom 2) ? 3) tag in repo app. The bad thing is that it's very easy to add a tag and we have so many tags already defined. Filtering is done through livetable's tag cloud. The bad thing is that it will be harder for us if in the future we will want to add that tag cloud also in EM. 4) type in repo app. 4) category? So not sure what is the difference between type and category. I would like a type in the repo app (so is this 1) or 4)?). We have a finite number of types and this way flavors will be special. If we want to add the filtering we just need to add a select inside EM (that will be able to filter apps, flavors, macros, colorthemes, pluggins, etc.). But you might not agree with me. Actually in the type field I would like to have: Apps, Flavors, Skins, even if all of them are XARs. I don't care how they are packaged, I care that they have different functionality, different purposes and different places to activate in the XE interface (Skins are activated in Administration, Apps are accessible in AppBar, Flavors will be suggested in the Wiki creation step). Thanks, Caty On Fri, Feb 6, 2015 at 12:14 PM, Thomas Mortagne <[email protected]> wrote: > OK I mixed a bit the number after a last miute refactoring of the mail... > > On Fri, Feb 6, 2015 at 11:09 AM, Thomas Mortagne > <[email protected]> wrote: > > Hi devs, > > > > There is many ways to make an extension a flavor and we need to chose > one. > > > > Here are a few I have in mind: > > > > 1) Extension of type FLAVOR (compared to XAR and JAR types for example) > > 2) A Boolean indicating if an extension is a flavor > > > 2) A tag "Flavor" (or some of the name to be decided later) > > 3) A unique category "Flavor" (or some of the name to be decided later) > > It's of course > > 3) A tag "Flavor" (or some other name to be decided later) > 4) A unique category "Flavor" (or some other name to be decided later) > > > > > I don't like 1) because a flavor does have anything special and I > > don't see the point of reimplementing a new extension type handler > > just to make an extension a flavor. > > > > I'm really not a fan for 2) either since it would makes this part of > > the core of extension API which I really don't like since flavor are > > XWiki runtime specific while you can use the xwiki-commons part of > > Extension Manager for many use cases that don't have anything to do > > with XWiki right now. > > > > So I'm hesitating between 3) and 4). When I started thinking about it > > I was more into 3) since we already have tags in XWiki Repository but > > since I saw that in both Android and IOS each application is in a > > > unique category I'm tempted to change my mind and give my +1 to 3). > > I'm sure you understood it's 4) here :) > > > Plus exposing categories is a nice new feature anyway. > > > > -- > > Thomas Mortagne > > > > -- > 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
