On Mon, Feb 3, 2020 at 10:13 AM Konstantin Kolinko <knst.koli...@gmail.com> wrote:
> сб, 1 февр. 2020 г. в 16:31, Michael Osipov <micha...@apache.org>: > > > > Am 2020-01-30 um 18:41 schrieb Konstantin Kolinko: > > > ср, 29 янв. 2020 г. в 00:08, Michael Osipov <micha...@apache.org>: > > > > > > [...] > > > > > > (Being too strict about language is a barrier that may reject people.) > > > > For those who don't know both, they don't care. For those who know care > > to make it right/consistent. I see no downsides to make it right. > > > > This has nothing to do with American, British, You Name It English. It > > is simply about consistent naming. > > I see no positive sides in the proposed renaming, > and I do not feel it to be a right thing. > It's hard to argue the usefulness of the fix is limited. I'm not going to -1 it though since the problem might be my fault (can't remember, that's convenient :) ). Rémy > > Some downsides were already mentioned by others. I will write down a > more complete list below. > > > For those who don't know both, they don't care. > > "i18n" is a more widely known and widely used word. > > Familiar words make people feel more comfortable. > > > > 2. In multi-module projects built with Apache Maven, one widely used > > > naming convention is to name artifacts produced by the nested modules > > > as <parentId>-<foo>. > > > > > > E.g., a discussion: > > > > https://stackoverflow.com/questions/9435460/maven-naming-conventions-for-hierarchical-multiple-module-projects > > > > > > I mean that the current artifact names of "tomcat-i18n-<locale>" can > > > be interpreted as module "<locale>" in a parent project "tomcat-i18n". > > > It means that those artifacts are part of internationalization effort > > > in Tomcat. > > > > I don't see how this is related?! Nor did I bring up to do any migration > > to Maven or its naming scheme. > > I mean that "tomcat-i18n" is the base name. > > It is not "tomcat" + "-i18n-de", but "tomcat-i18n" + "-de", as an example. > > The current names are not wrong. > > > > > 3. Overall, my vote for this proposal is -0.5. > > > > > > It is not a veto, but I do not like it. > > > > So you generally do not object, but don't see a need for? > > I really object. > I just do not veto, I do not end the discussion here at once. > > > If there were other reasons to justify the change (e.g. some > reorganization of packaging), ... > > (E.g. all translation files could be packaged into a single jar.) > > > I see no downsides ... > > To make it clear, the following are externally visible consequences of > such a change: > > 1. Renaming of artifacts in Maven > 2. Renaming of libraries in ${catalina.base}/lib > 3. Change of configuration in conf/catalina.properties file (the > libraries are mentioned in a jarsToSkip pattern). > > The following are internal changes: > 4. Changes in build procedure (in build.xml, res/maven/mvn-pub.xml). > 5. Changes in documentation (class-loader-howto.xml mentions the files). > > ##1-3 are the downsides that downstream consumers of Tomcat would have > to adapt to. > > I certainly would have to change some of my scripts that I use with > Tomcat and some configuration settings. > > ##4-5 are our internal matter. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
