6 Feb
2015
6 Feb
'15
11:09 a.m.
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)
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).
Plus exposing categories is a nice new feature anyway.
--
Thomas Mortagne
6 Feb
6 Feb
11:14 a.m.
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
<thomas.mortagne(a)xwiki.com> 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
12:09 p.m.
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 <thomas.mortagne(a)xwiki.com>
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
<thomas.mortagne(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:11 p.m.
So I guess in the pom it should be xar - but of category: flavor? :) I'm
not sure how it will be defined
On Fri, Feb 6, 2015 at 1:09 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
wrote:
> 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 <
> thomas.mortagne(a)xwiki.com 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
>> <thomas.mortagne(a)xwiki.com
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
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
12:21 p.m.
I'm not talking about implementation here, I'm talking about logic so
please forget about maven and repository manager.
Since it seems to not be clear enough lets try to redo the list:
1) this is a special new type of extension, it's not a XAR and it's
not a JAR. It has it's own handler, install/uninstall behavior,
rights, etc
2) In Extension you have isFlavor() which return true or false
3) in Extension you get a list of tags and one of them may be "Flavor"
meaning this extension is a flavor
4) in Extension you have a category and it might be "Flavor" meaning
this extension is a flavor
On Fri, Feb 6, 2015 at 12:09 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
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 <thomas.mortagne(a)xwiki.com>
wrote:
--
Thomas Mortagne
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
<thomas.mortagne(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:52 p.m.
Thomas,
for 3) can you give me some example of what the other tags might be? except
Flavor? Can extension be of multiple tags?
Until now I think I prefer 4)
Thanks,
Caty
On Fri, Feb 6, 2015 at 1:21 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
I'm not talking about implementation here, I'm
talking about logic so
please forget about maven and repository manager.
Since it seems to not be clear enough lets try to redo the list:
1) this is a special new type of extension, it's not a XAR and it's
not a JAR. It has it's own handler, install/uninstall behavior,
rights, etc
2) In Extension you have isFlavor() which return true or false
3) in Extension you get a list of tags and one of them may be "Flavor"
meaning this extension is a flavor
4) in Extension you have a category and it might be "Flavor" meaning
this extension is a flavor
On Fri, Feb 6, 2015 at 12:09 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <
thomas.mortagne(a)xwiki.com>
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
> <thomas.mortagne(a)xwiki.com> 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)
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:43 p.m.
Hi,
IMO, a Flavor is a type of extension, but extension type should not be a
packaging characteristic, but a functional one (e.g. skin, macro,
application, flavor, group, etc).
xar, jar, zip, rar, etc. should be strictly a packaging technical detail of
the Extension Manager's inner workings.
I guess that my +1 goes to option 4), where an extension has 1 single value
declaring its type (you said category, I think it should be type, from the
user's POV).
Again, from an user's POV, an extension should also declare one or more
categories it is part of, thus declaring its objective/business
logic/area/domain/etc.
Let's take a real-work example for a physical tool/product such as a hammer.
name: HandyCo X300
type: hammer
category: building, carpentry
packaging: cardboard box
For applications:
name: App Within Minutes - UI
type: application
category: development, ease of use, etc.
packaging: xar
For flavors:
name: Public Website
type: flavor
category: publishing, etc.
packaging: xar (can be empty xar just with dependencies or it can have
custom preferences for that flavor like what skin to use, what rights to
have, etc.)
One note here is that we could also have a subtype. The use cases where
this might be useful would be macros (wiki macros, java macros, velocity
macros, etc.), themes (color theme, flamingo theme, etc.), applications
(standalone applications, AWM applications) etc. Not sure about this one,
food for thought for now, but the idea is that you might want to look for
"macros" at some point, but maybe at some other point you want to look just
for wiki macros. Maybe this can be achieved with simple filtering/("like"
queries) instead of using an actual field.
Thanks,
Eduard
On Fri, Feb 6, 2015 at 1:52 PM, Ecaterina Moraru (Valica) <valicac(a)gmail.com
wrote:
> Thomas,
>
> for 3) can you give me some example of what the other tags might be? except
> Flavor? Can extension be of multiple tags?
>
> Until now I think I prefer 4)
>
> Thanks,
> Caty
>
> On Fri, Feb 6, 2015 at 1:21 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com
> >
wrote:
>
> > I'm not talking about implementation here, I'm talking about logic so
> > please forget about maven and repository manager.
> >
> > Since it seems to not be clear enough lets try to redo the list:
> >
> > 1) this is a special new type of extension, it's not a XAR and it's
> > not a JAR. It has it's own handler, install/uninstall behavior,
> > rights, etc
> > 2) In Extension you have isFlavor() which return true or false
> > 3) in Extension you get a list of tags and one of them may be
"Flavor"
> > meaning this extension is a flavor
> > 4) in Extension you have a category and it might be "Flavor" meaning
> > this extension is a flavor
> >
> >
> > On Fri, Feb 6, 2015 at 12:09 PM, Ecaterina Moraru (Valica)
> > <valicac(a)gmail.com wrote:
> > >
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 <
> > thomas.mortagne(a)xwiki.com>
> > 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
> > >> <thomas.mortagne(a)xwiki.com
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
> > >> devs(a)xwiki.org
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Thomas Mortagne
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
17 Feb
17 Feb
5:18 p.m.
Hi,
I agree with Edy that we shouldn’t mix the type of an extension with the categories it
belongs to.
Said differently I wouldn’t like to see an extension put in both the “flavor” and the
“drawing” categories. It would be comparing apples and oranges.
So it would seem that there are 3 different notions:
* The extension packaging: XAR, JAR
* The extension type(s) (what it is): flavor, application, wiki macro, skin, library
* The extension categories (what it does): drawing, editor, authentication, mail, etc
At the implementation level we could imagine using XWiki Tags for representing extension
categories. We may want to have hierarchical tags in the future though. Having tags have
pros and cons, one of the being that users can create new categories on the fly. We would
need to decide if we want that or if we wish to control the category list.
Thanks
-Vincent
On 6 Feb 2015 at 13:43:35, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
Hi,
IMO, a Flavor is a type of extension, but extension type should not be a
packaging characteristic, but a functional one (e.g. skin, macro,
application, flavor, group, etc).
xar, jar, zip, rar, etc. should be strictly a packaging technical detail of
the Extension Manager's inner workings.
I guess that my +1 goes to option 4), where an extension has 1 single value
declaring its type (you said category, I think it should be type, from the
user's POV).
Again, from an user's POV, an extension should also declare one or more
categories it is part of, thus declaring its objective/business
logic/area/domain/etc.
Let's take a real-work example for a physical tool/product such as a hammer.
name: HandyCo X300
type: hammer
category: building, carpentry
packaging: cardboard box
For applications:
name: App Within Minutes - UI
type: application
category: development, ease of use, etc.
packaging: xar
For flavors:
name: Public Website
type: flavor
category: publishing, etc.
packaging: xar (can be empty xar just with dependencies or it can have
custom preferences for that flavor like what skin to use, what rights to
have, etc.)
One note here is that we could also have a subtype. The use cases where
this might be useful would be macros (wiki macros, java macros, velocity
macros, etc.), themes (color theme, flamingo theme, etc.), applications
(standalone applications, AWM applications) etc. Not sure about this one,
food for thought for now, but the idea is that you might want to look for
"macros" at some point, but maybe at some other point you want to look just
for wiki macros. Maybe this can be achieved with simple filtering/("like"
queries) instead of using an actual field.
Thanks,
Eduard
On Fri, Feb 6, 2015 at 1:52 PM, Ecaterina Moraru (Valica) > > wrote:
> Thomas,
>
> for 3) can you give me some example of what the other tags might be? except
> Flavor? Can extension be of multiple tags?
>
> Until now I think I prefer 4)
>
> Thanks,
> Caty
>
> On Fri, Feb 6, 2015 at 1:21 PM, Thomas Mortagne > > >
> wrote:
>
> > I'm not talking about implementation here, I'm talking about logic so
> > please forget about maven and repository manager.
> >
> > Since it seems to not be clear enough lets try to redo the list:
> >
> > 1) this is a special new type of extension, it's not a XAR and it's
> > not a JAR. It has it's own handler, install/uninstall behavior,
> > rights, etc
> > 2) In Extension you have isFlavor() which return true or false
> > 3) in Extension you get a list of tags and one of them may be
"Flavor"
> > meaning this extension is a flavor
> > 4) in Extension you have a category and it might be "Flavor" meaning
> > this extension is a flavor
> >
> >
> > On Fri, Feb 6, 2015 at 12:09 PM, Ecaterina Moraru (Valica)
> > wrote:
> > > 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 <
> > thomas.mortagne(a)xwiki.com>
> > > 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
> > >> 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
10 Feb
10 Feb
9:41 a.m.
+1 for 4) (unique category/type that is specific to the XWiki
Extension Repository).
Thanks,
Marius
On Fri, Feb 6, 2015 at 12:14 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> 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
<thomas.mortagne(a)xwiki.com> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3552
days inactive
3563
days old
8 comments
5 participants
participants (5)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net