[jbosstools-dev] [i18n] NON-NLS warnings by module

[Sean Flanigan]

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