Re: [xwiki-devs] [PROPOSAL] So what do we do for our Maven projects names

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

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

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

stopwords around those keywords (like Extension Repository *for* Maven)

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.

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 &lt;dgl(a)softec.lu&gt; wrote: > On Tue, Oct 9, 2012 at 11:19 AM, Vincent Massol &lt;vincent(a)massol.net&gt; > wrote: > >> >> On Oct 9, 2012, at 11:09 AM, Thomas Mortagne <

>> 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

> the information lost in changing names are still displayed in EM, since > these information are still useful IMO. I take the occasion to also

> that EM currently do not seems to sort the list by any means, and this

> the list not really browsable. And if you think about sorting, the

> names are not badly suited. > > There is IMO a 4) option, just to be complete since I am not sure I

> be in favor, which is to manage the issue in the UI, parsing our names

> displaying them differently, to be just more pretty. > > I would prefer to keep only one name, using the maven one, so 2) seems

> 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

> convention is closely linked to this vote. > > >> >> Thanks >> -Vincent