On Thu, Jan 24, 2013 at 8:42 PM, Denis Gervalle <[email protected]> wrote: > On Tue, Nov 27, 2012 at 7:16 PM, Vincent Massol <[email protected]> wrote: > >> >> On Nov 27, 2012, at 6:59 PM, Eduard Moraru <[email protected]> wrote: >> >> > Hi, >> > >> > I`m with Denis on this one. >> > >> > Besides knowing from which module the sub-module is, you also lose >> > top-module information. Couple that with the fact that we have some >> modules >> > with almost identical names in both platform and commons (due to partial >> > moving to commons of some sub-modules), it will become a bit tricky to >> know >> > which one is actually mentioned. Displaying the extension ID in the EM >> > would help a bit on this aspect. >> > >> > Another inconvenient of pretty names is that they can get messy fast. In >> > lack of a convention, we risk confusing users more than helping them. >> > Besides that, we will be very tempted to name modules by a similar scheme >> > that we have today, due to the hierarchical nature and the "part-whole" >> > relationship between modules. I am not sure on what improvement we will >> > have with this approach (option 2), instead of maybe dropping the "-" >> > characters from the pretty name. >> > >> > Extension search also should work on, since users search for keywords and >> > that's generally what we use right now in the module names. Adding a lot >> of >> > stopwords around those keywords (like Extension Repository *for* Maven) >> is >> > not much of an UX improvement IMO. >> > >> > Do we, by any chance have some reports/complaints from user about the >> > current way of naming extensions? I find the we currently have a decent >> > balance between technical and pretty names. We generally have 3 to 4 >> > components in the module's name and, rarely, in some modules that are not >> > really exposed to the user (corner cases), we might exceed that to 5-6. >> >> What Thomas and I are proposing is exactly that: to keep the current names >> on e.x.o. Now what you propose when you vote +1 for 1) is the opposite, >> i.e. for example instead of having "Blog Application" you'd have "XWiki >> Platform - Blog - UI" (on >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Blog+Application). I >> don't see how worse it could be… :) >> >> The reason we don't have any complaints is exactly because those names are >> good! >> > > Sorry to revive this the hard way, but I have to complaint ! > > When I startup my freshly upgraded 4.4.1 Wiki, DW came in and propose me to > upgrade: > > XWiki Platform - Application Manager - API 4.3.1 (Upgradable) > XWiki Platform - Wiki Manager - UI 4.3.1 (Upgradable) > XWiki Platform - Wiki Manager - API 4.3.1 (Upgradable) > > A optional proposal I have discarded. > In EM, I see, among others, the following installed extensions: > > XWiki Platform - Administration - UI 4.4.1 (Uninstallable) > XWiki Platform - Application Manager - API 4.3.1 (Uninstallable) > XWiki Platform - Wiki Manager - UI 4.3.1 (Uninstallable) > XWiki Platform - Wiki Manager - API 4.3.1 (Uninstallable) > > but into Add Extension, it propose me, among others, the following: > > Administration Application 4.4.1 (Uninstallable) > Application Manager API 4.4.1 (Upgradable) > Application Manager Application 4.2 (Instalable) > Wiki Manager Application 4.4.1 (Upgradable) > > Except if I am an expert in XWiki packages, I cannot understand some of > these are the same extensions, others are not. > This cause IMO a lot of confusion, and is almost unusable as is. > Since, we are at the stabilisation stage of our cycle, I expect many will > start looking at DW and EM, and could really get confused, both by the > different status depending on which list you look at, but even more by the > same package taking different names. > Since we were unable to find an agreement of how to name packages, we are > currently impacting a lot usability. > This also block the automation of the upgrade of extension.xwiki.org to the > latest version, and therefore increase confusion even more, and overcharge > the RM. > So, even if we cannot settle our decision on names, at least we need to > make them consistant ASAP. > > WDYT ?
Which is my point... Lets repeat it again: we don't care what the name are, this mail is about choosing where the name are located in a pom.xml. It's the only thing that matters. So please vote on what is asked now and don't change subject. > > >> Thanks >> -Vincent >> >> > So my vote is: >> > +1 for 1) >> > +0 for 2) >> > -1 for 3) >> > >> > Thanks, >> > Eduard >> > >> > >> > >> > On Tue, Oct 9, 2012 at 2:49 PM, Denis Gervalle <[email protected]> wrote: >> > >> >> On Tue, Oct 9, 2012 at 11:19 AM, Vincent Massol <[email protected]> >> >> wrote: >> >> >> >>> >> >>> On Oct 9, 2012, at 11:09 AM, Thomas Mortagne < >> [email protected]> >> >>> wrote: >> >>> >> >>>> Hi devs, >> >>>> >> >>>> In order to automate the update of extensions imported from >> >>>> https://github.com/xwiki/ we need to have nothing to modify when an >> >>>> import is done. >> >>>> >> >>>> The last remaining thing is the name on which there is a debate is the >> >>>> name. Right now the name we have in our maven project looks like >> >>>> "XWiki Commons - Extension - Repository - Maven" so that's what we get >> >>>> when importing this project or when viewing it in EM UI. >> >>>> >> >>>> Some of us want to keep this idish name for Maven build but don't like >> >>>> it when displaying extension. I recently introduced a way to overwrite >> >>>> some extension related informations like the name based on properties. >> >>>> >> >>>> So here are the choices we have: >> >>>> >> >>>> 1) Do nothing which mean display "XWiki Commons - Extension - >> >>>> Repository - Maven" in EM UI and extensions.xwiki.org >> >>>> 2) Change our naming in Maven <name> property for it to be more a name >> >>>> than an id that would looks good in EM UI >> >>>> 3) Keep the same naming for Maven <name> and overwrite it everywhere >> >>>> using <xwiki.extension.name> property >> >>>> >> >>>> So, WDYT ? >> >>>> >> >>>> The one that makes the more sense to me is 2) so my +1 goes to this >> >>>> one. Frankly I don't care too much having the current id based display >> >>>> of the summary of built modules in Maven build and I personally won't >> >>>> have any issue to know what name correspond to what project (but >> >>>> that's because I know them well, I can understand new dev could be a >> >>>> bit more lost). >> >>>> >> >>>> Then: >> >>>> * +0 for 3) to +0 (I don't like too much having this special case >> >>>> everywhere in our Maven pom.xml) >> >>>> * -0 for 1) (I agree that it does not looks very nice as a display >> >> name). >> >>> >> >>> Exactly the same as Thomas for me. I'd really like if we could find a >> >>> solution that works for 2). Even in Maven it's supposed to be a name, >> >> i.e. >> >>> something readable, not an id… Now even with 2) we would still need a >> >>> naming rule and have some concise name. >> >>> >> >> >> >> If you want name to be more pretty and concise, we should also discuss >> how >> >> the information lost in changing names are still displayed in EM, since >> >> these information are still useful IMO. I take the occasion to also >> mention >> >> that EM currently do not seems to sort the list by any means, and this >> make >> >> the list not really browsable. And if you think about sorting, the >> current >> >> names are not badly suited. >> >> >> >> There is IMO a 4) option, just to be complete since I am not sure I >> would >> >> be in favor, which is to manage the issue in the UI, parsing our names >> and >> >> displaying them differently, to be just more pretty. >> >> >> >> I would prefer to keep only one name, using the maven one, so 2) seems >> the >> >> best option after doing nothing, but I am not really happy to loose the >> >> information we have in names currently. So I agree with Vincent, the >> naming >> >> convention is closely linked to this vote. >> >> >> >> >> >>> >> >>> Thanks >> >>> -Vincent >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > 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
