Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ilya.okomin@gmail.com designates
 66.249.92.172 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=O1ic/f3t3r6JnMMdJyXx10YfxY29nkG1fiGAjZ97UcPN1a1ZEXxCJ3EXiiR9XCHMnHo6mS61nSm1Kjkvi3gyzzUurJLgOiTRAXfzJBv3SobZ9gjBexMxBjzSd5B60ycSFBrQbxXiUagCUt3VhkndDbQSdc5ma7miBeTZaJkmccg=
Message-ID: <c79906b30607270733n1e07b54ar75077b8d2ae91716@mail.gmail.com>
Date: Thu, 27 Jul 2006 18:33:42 +0400
From: "Ilya Okomin" <ilya.okomin@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib]strings externalization
In-Reply-To: <44C8BB94.5030300@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_277218_16225282.1154010822887"
References: <c79906b30607270353y4dfdb16bw92bc48fed76cb1c0@mail.gmail.com>
	 <44C8AE2A.8000807@gmail.com>
	 <c79906b30607270550pc6aeb1ej2a50d2ff80e80ea@mail.gmail.com>
	 <44C8BB94.5030300@gmail.com>

------=_Part_277218_16225282.1154010822887
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 7/27/06, Tim Ellison <t.p.ellison@gmail.com> wrote:

> Ilya Okomin wrote:
> > On 7/27/06, Tim Ellison <t.p.ellison@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
--
Ilya Okomin
Intel Middleware Products Division

------=_Part_277218_16225282.1154010822887--