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