On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Ilya Okomin wrote:
> On 7/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>> The other reason we will need some manual intervention is that there is
>> plenty of code that throws exceptions without any message describing
the
>> problem, and of course the tooling won't help there.
>
> Tim, do you mean, that Exceptions without any messages supposed to be
> initialized with some corresponding message describing the problem? I
> thought only already existing in modules messages are to be considered.
> Just want to dispel doubts.
I see plenty of code going in to svn that simply throws a new
IllegalArgumentException() or whatever. It would be good if they had an
externalized message to explain what the problem was -- i.e. throw new
IllegalArgumentException("Parameter foobar should be less than 42") etc.
You might consider this a separate task to that of externalizing the
existing messages, but depending on how 'manual' the externalization
scan is for each module it may be worth doing both simultaneously.
I share your point of view about Exceptions without description, it isn't
user friendly. But I think it will be another sort of 'manual' scan :) There
is a need to waste time to analyze surrounding code to provide appropriate
message, a bit another sort of work, isn't it?
I think the best way would be if all these Exceptions without info are being
identified before externalization process is to be ran. For today I'd
better postpone the task of initialization 'empty' exceptions until the
externalization is finished.
>> So once we have the basic framework in place for the message handling I
>> think it will require a large manual effort to get all the strings that
>> we want externalized properly. Luckily it is not technically complex
>> work and it is a task that we can easily do in parallel across the
>> modules.
>
> Yep, I've chosen the same way to do.
Cool -- did you get anywhere with the message handling framework
'template' code?
I've implemented a small tool that generates Message source and MsgHelp
source into a desired module. Tool gets a list of modules names from
property file (you can specify modules class sources to generate for),
then we run over the list and special word '<module>' in Message and MsgHelp
source templates files replaced with the specified module name. Resulting
sources are copied to the o/a/h/<module>/internal/ directory. At first I
planned to use MsgHelp class from luni but after a while I've decided to
avoid dependency on luni module and included generation source file of this
class to every module.
Thus Message or MsgHelp source files can be easy regenerated for a desired
set of modules, if anything is changed there.
I plan to add creation of a new empty messages.properties files with
copyright heading if it is absent for the module. Also I think that it make
sense to changle location to o/a/h/<module>/internal/nls.
Will provide patch with this tool when these changes are to be implemented
and checked.
Thanks,
Ilya.
Regards,
Tim
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Ilya Okomin
Intel Middleware Products Division
