Hi. > > > But it's more effort to build the code, > > > > > > Is your computer threatening to go on strike? ;-) > > No, but you already said that you don't know how to update the Maven > builds to cope with the extra jars.
Does that mean "Don't propose anything unless you are able to carry it on all by yourself"? > Also, the standard commons download page generation may need to be > changed to deal with the extra jars. Hmm, let's go back a little. The proposed mechanism was aimed at providing a self-contained version of CM, to which some people hold dearly. Now is it still true that some users *require* a zero-dependency CM? At least I'm not one of them. If we remove the "no-dependency" requirement and select CAL10N as our library of choice for localization, then there is no need for the several JARs. > [...] > > > > Maintaining two copies of the English messages. > > > > > > I'll do it. [I bet that arguing on this has already taken more time than > > several revisions of these files.] > > This is getting a bit away from the the point. > > I think we should either go for CAL10N entirely, or not at all. > Having a fallback that is not essential AND requires ongoing extra > work does not seem sensible to me. So does one priority (zero dependency) override the other (extra work)? I proposed a middle-ground solution, but as I said, I have no problem with your first alternative. It is indeed easier to implement, and there is nothing to explain to users. > > I must add that maintaining these 2 copies is still *much* less work that > > the current way of having a "bundle" for each language, repeating the > > English message text in each language file. Well, in fact, there is > > already > > 2 copies of the English messages (one in the code and one in the > > "messages_fr" file). So from this particular point-of-view, right now my > > proposal is on a par with the current way, and it wan only be better as > > more > > translations are added! > > Yes, but why make it less efficient than it need be? Because of diverse requirements, maybe? > > It seems that you over-estimate the work, because of the current way of > > doing it in CM (cf. the original mail of my proposal). > > In the new way, only the creator of a new exception class will have to deal > > with the text messages (1 default in the Java code + 1 in the English file > > + 1 for each other language file). From that point on, developers will just > > deal with the constructor of that exception class (no text message > > involved). > > I think this will all become a lot clearer when the sandbox project is > established. In light of your comments, I now think that we should first decide on whether external dependencies are acceptable. If they are, then setting up the Maven system to produce unnecessary artefacts is obviously not a priority. > We can then see how many SVN updates are needed to maintain the code. I don't understand this. [In the code, the overwhelming majority of changes will be the modification of the "throw" statements. Afterwards, with or without the "bridge" part of the code, the maintenance will be almost the same (i.e. apart from the "extra" update of the English properties file).] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
