11:43 p.m.
G'day
To help me gauge how much work is left in
https://jira.jboss.org/jira/browse/JBIDE-3557, I have modified all the
projects' .settings (in my local workspace) to enable NON-NLS
(unexternalized string) warnings, and counted the number of warnings for
each module.
Here's a spreadsheet if anyone's interested:
http://spreadsheets.google.com/ccc?key=r8p7PNL8gpWp61vrYehBjVw
I would ask for help to count these warnings automatically as part of
the Hudson build, but it's probably not worth the effort for a temporary
issue. (Tracking for all sorts of warnings might be though...)
However, I do think it would be worthwhile to enable NON-NLS *errors* in
the Hudson build, progressively, as each module is cleaned up. This
would help to ensure the module stays clean[1]. Does this sound
possible/practical?
Also, it would be a big help if everyone can keep an eye out for NON-NLS
warnings when changing code (or writing new code). This will save me
having to go back to modules I've already finished, because
unexternalized strings have crept in. Thanks!
Regards
Sean
[1] It would be easy to enable NON-NLS errors in the projects' .settings
for everyone, but we probably don't want to force everyone to
internationalise their code before running a local unit test.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
4:47 a.m.
G'day
To help me gauge how much work is left in
https://jira.jboss.org/jira/browse/JBIDE-3557, I have modified all the
projects' .settings (in my local workspace) to enable NON-NLS
(unexternalized string) warnings, and counted the number of warnings
for each module.
Here's a spreadsheet if anyone's interested:
http://spreadsheets.google.com/ccc?key=r8p7PNL8gpWp61vrYehBjVw
ouch - you make it
looks so clear that i hurts...
I would ask for help to count these warnings automatically as part of
the Hudson build, but it's probably not worth the effort for a
temporary issue. (Tracking for all sorts of warnings might be though...)
Yes, I
got a long list of warnings/errors I would like to enable *cross*
project but I haven't found a good way of doing that (beyond adding a
.settings file to every project which is very much overkill and
unmaintainable IMO)
Nick - got any suggestions ?
However, I do think it would be worthwhile to enable NON-NLS *errors*
in the Hudson build, progressively, as each module is cleaned up.
This would help to ensure the module stays clean[1]. Does this sound
possible/practical?
When we got the build separated out in modules i'm all for
this - but
for now where eevery build depends on everything else to build this
would be too invasive at this point in time.
Also, it would be a big help if everyone can keep an eye out for
NON-NLS warnings when changing code (or writing new code). This will
save me having to go back to modules I've already finished, because
unexternalized strings have crept in. Thanks!
+1
/max
7:15 p.m.
On 06/04/2009 07:47 PM, Max Rydahl Andersen wrote:
> Here's a spreadsheet if anyone's interested:
> http://spreadsheets.google.com/ccc?key=r8p7PNL8gpWp61vrYehBjVw
ouch - you make it looks so clear that i hurts...
You mean the way jst, jsf and vpe all depend on each other? Scary.
It was even worse before I eliminated all tests from the dependency
scan, because the tests in common apparently depend on something in
jsf/jst/vpe, thus pulling in all three of them.
I must say, I was hoping to find a smaller set of strings in the "must
be translated first" basket. "common" has 25% of the unexternalized
strings in the codebase!
> I would ask for help to count these warnings automatically as
part of
> the Hudson build, but it's probably not worth the effort for a
> temporary issue. (Tracking for all sorts of warnings might be though...)
Yes, I got a long list of warnings/errors I would like to enable *cross*
project but I haven't found a good way of doing that (beyond adding a
.settings file to every project which is very much overkill and
unmaintainable IMO)
Nick - got any suggestions ?
I hope Nick has something better, but I've got a couple of low-tech ideas.
1. Have a script on the build server which would copy a template
.settings folder to each plugin when building. Then we put our
strictest settings into the template so that they will be used on the
server.
2. OR, outlaw per-project .settings (for the most part). I don't know
about PDE Build, but in this case the Eclipse IDE would use the general
workspace preferences, which can be customized for each machine, and for
the build server. Then we would put whatever strict workspace prefs we
like on the build server. (Perhaps it could import a .epf file
maintained in svn?)
> However, I do think it would be worthwhile to enable NON-NLS
*errors*
> in the Hudson build, progressively, as each module is cleaned up.
> This would help to ensure the module stays clean[1]. Does this sound
> possible/practical?
When we got the build separated out in modules i'm all for this - but
for now where eevery build depends on everything else to build this
would be too invasive at this point in time.
Well, I wouldn't say every build depends on everything else. Some of
the modules are huge, which makes things a bit harder for me. But the
circularity isn't too bad, apart from jsf/jst/vpe/common-tests.
Admittedly, that cluster is huge in string count, and presumably LOC,
but the size of the modules shouldn't affect the complexity of the build.
Would it be possible to pull common/*.test (or */*.test) out into a new
module, or perhaps the tests module? That would help.
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
1:24 a.m.
On 06/05/2009 10:15 AM, Sean Flanigan wrote:
I hope Nick has something better, but I've got a couple of
low-tech ideas.
[snip two useless suggestions]
Oh. I've done a bit more reading. Apparently PDE Build ignores
per-project settings [1]. Which I'm sure everyone else already knew. I
suppose I had assumed that Eclipse had more integration between batch
builds and IDE builds.
Still, it looks as if enabling warnings on the build server should be
pretty easy: we just have to set (eg) compilerArg=-warn:nls in
build.properties. [2]
That only leaves the problem of where all these warnings will end up.
If we don't change anything else, I imagine they'll just end up in
Hudson's console output. Even that would be a start, since we could
just grep it for interesting warnings, count them, etc etc. Eventually,
tracking compiler warnings the way PMD warnings are tracked might be
nice. There's a plugin [3] that sounds pretty good for this.
Sean.
[1] http://wiki.eclipse.org/PDE/Build "PDE/Build does not know anything
about the Java Builder settings in your workspace or on your project.
Your plug-in's manifest.mf and build.properties files are the input to
PDE/Build."
[2]
http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.jdt.doc.isv...
"Warning options"
[3] http://wiki.hudson-ci.org/display/HUDSON/Warnings+Plugin
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
1:32 p.m.
I was quite horrified to find JMX had 74 remaining errors. They've now
been fixed.
Interestingly, over a dozen or more of these errors were because NON-NLS
was put on a line it didnt' need to be, rather than a string missing
externalization.
Max Rydahl Andersen wrote:
> G'day
>
> To help me gauge how much work is left in
> https://jira.jboss.org/jira/browse/JBIDE-3557, I have modified all
> the projects' .settings (in my local workspace) to enable NON-NLS
> (unexternalized string) warnings, and counted the number of warnings
> for each module.
>
> Here's a spreadsheet if anyone's interested:
> http://spreadsheets.google.com/ccc?key=r8p7PNL8gpWp61vrYehBjVw
ouch - you make it looks so clear that i hurts...
> I would ask for help to count these warnings automatically as part of
> the Hudson build, but it's probably not worth the effort for a
> temporary issue. (Tracking for all sorts of warnings might be
> though...)
Yes, I got a long list of warnings/errors I would like to enable
*cross* project but I haven't found a good way of doing that (beyond
adding a .settings file to every project which is very much overkill
and unmaintainable IMO)
Nick - got any suggestions ?
> However, I do think it would be worthwhile to enable NON-NLS *errors*
> in the Hudson build, progressively, as each module is cleaned up.
> This would help to ensure the module stays clean[1]. Does this sound
> possible/practical?
When we got the build separated out in modules i'm all for this - but
for now where eevery build depends on everything else to build this
would be too invasive at this point in time.
> Also, it would be a big help if everyone can keep an eye out for
> NON-NLS warnings when changing code (or writing new code). This will
> save me having to go back to modules I've already finished, because
> unexternalized strings have crept in. Thanks!
+1
/max
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
12:53 a.m.
Hi Rob,
Thanks for cleaning up JMX! I see you've even enabled NON-NLS errors.
You were asking on IRC about the 2 warnings in archives. See
/packaging-convert/src/org/jboss/tools/archives/JBossIDEtoTools.java
That package seems to be an odd-man-out (util rather than plugin), but
it does live under trunk/archives, which is why it ended up in the results.
About the "dozen or more" errors: I don't think the String
Externalization wizard always removes NON-NLS comments when
externalizing a string. Something like that, anyway. And if something
trigger code reformatting, Eclipse doesn't move the NON-NLS comments to
follow the string.
So it's not hard for those warnings to accumulate. Find Broken
Externalized Strings can pick these things up, among other problems.
Sean.
On 06/09/2009 04:32 AM, Rob Stryker wrote:
I was quite horrified to find JMX had 74 remaining errors.
They've now
been fixed.
Interestingly, over a dozen or more of these errors were because NON-NLS
was put on a line it didnt' need to be, rather than a string missing
externalization.
Max Rydahl Andersen wrote:
>> G'day
>>
>> To help me gauge how much work is left in
>> https://jira.jboss.org/jira/browse/JBIDE-3557, I have modified all
>> the projects' .settings (in my local workspace) to enable NON-NLS
>> (unexternalized string) warnings, and counted the number of warnings
>> for each module.
>>
>> Here's a spreadsheet if anyone's interested:
>> http://spreadsheets.google.com/ccc?key=r8p7PNL8gpWp61vrYehBjVw
> ouch - you make it looks so clear that i hurts...
>> I would ask for help to count these warnings automatically as part of
>> the Hudson build, but it's probably not worth the effort for a
>> temporary issue. (Tracking for all sorts of warnings might be
>> though...)
> Yes, I got a long list of warnings/errors I would like to enable
> *cross* project but I haven't found a good way of doing that (beyond
> adding a .settings file to every project which is very much overkill
> and unmaintainable IMO)
>
> Nick - got any suggestions ?
>
>> However, I do think it would be worthwhile to enable NON-NLS *errors*
>> in the Hudson build, progressively, as each module is cleaned up.
>> This would help to ensure the module stays clean[1]. Does this sound
>> possible/practical?
> When we got the build separated out in modules i'm all for this - but
> for now where eevery build depends on everything else to build this
> would be too invasive at this point in time.
>> Also, it would be a big help if everyone can keep an eye out for
>> NON-NLS warnings when changing code (or writing new code). This will
>> save me having to go back to modules I've already finished, because
>> unexternalized strings have crept in. Thanks!
> +1
>
> /max
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
5445
days inactive
5450
days old
jbosstools-dev@lists.jboss.org
5 comments
3 participants
participants (3)
-
Max Rydahl Andersen -
Rob Stryker -
Sean Flanigan