сб, 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. 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
