[
https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu...
]
Sean Flanigan commented on JBIDE-4044:
--------------------------------------
Find Broken Externalized Strings still finds about 300 problems (most counted twice, so
closer to 150 really), but I think we've grabbed most of the low-hanging fruit. (This
issue started with 294, but that was measured with a different tool, and before we added
modules like bpel.)
However, there are still a couple of bundles which have over 20 reported problems each
(over 40 with double counting), so I've added sub-tasks for them. The other strings
are spread over about 20 ResourceBundles, so I don't think it's worth
micromanaging them.
Unless we find a way of integrating FBES reports into the build, it's probably not
worth trying to get the number down to zero anayway, since it won't stay there. (A
Hudson plugin would be nice, but I don't think there's any way of automating it
yet. AFAIK, PDE Build can't Find Broken Externalized Strings anyway, since only the
IDE would build the necessary indexes.)
Review unused strings as reported by "Find Broken Externalized
Strings"
-----------------------------------------------------------------------
Key: JBIDE-4044
URL:
https://jira.jboss.org/jira/browse/JBIDE-4044
Project: Tools (JBoss Tools)
Issue Type: Task
Components: Cleanup
Affects Versions: 3.1.0.M1
Reporter: Sean Flanigan
Assignee: Sean Flanigan
Fix For: 3.1.0.M2
Attachments: unused_messages_in_jbosstools.zip
I've run UCDetector [1] against the codebase, and it has found 294
fields in *Messages classes which have 0 references. I've attached a
list (views well in oocalc). I'd like to remove them, along with their
corresponding resourcebundle properties, to reduce the number of
translatable strings before localisation begins.
I think it should be safe to remove these fields, since any direct usage will be caught
by the compiler as soon as we try to remove it (and wouldn't have been listed by
UCDetector anyway, unless it is completely broken), and it would be extremely unlikely for
anyone to access a Messages field by reflection.
If you want to run UCDetector yourself, select one or more plugin projects (not features,
not non-Java projects), select UCDetector/Detect unnecessary code, and wait. I recommend
configuring Eclipse's Problems view to show problems of type "UCDetector Marker
(References)" whose description contains 'Field "'. The relevant
problems are of the form 'Field SomethingMessages.SOME_KEY" has 0
references'.
[1]
http://ucdetector.sourceforge.net/
EDIT:
Forget about UCDetector for this! It looks like Eclipse's built in feature
"Find Broken Externalized Strings" is much better for this specific case. Not
to mention a lot faster!
Looking through the results, I'm getting an idea what Max meant about false
positives, because some properties files are used both through a Messages accessor class
and directly via ResourceBundle, sometimes by concatenating prefixes to construct the
keys. Like Eclipse, I assumed that wouldn't happen to a bundle which has a Messages
accessor class, but I was obviously wrong.
I would suggest switching to "Find Broken Externalized Strings", because
(unlike UCDetector) it can handle properties files accessed through old-style Messages
classes with getString() methods.
You can run Source/Find Broken Externalized Strings against a package, project, or group
of projects. I've cleaned up as well as I can, and reviewed the supposedly
"undefined keys". Here is the resulting list of resourcebundles with at least
20 suspected unused keys:
archives:
ArchivesUIMessages.properties -
org.jboss.ide.eclipse.archives.ui/src/main/org/jboss/ide/eclipse/archives/ui (43 matches)
(accessor class org.jboss.ide.eclipse.archives.ui.ArchivesUIMessages)
common:
JavaUIMessages.properties -
org.jboss.tools.common.model.ui/src/org/jboss/tools/common/model/ui/util (69 matches)
XmlEditorMessages.properties -
org.jboss.tools.common.text.xml/src/org/jboss/tools/common/text/xml/ui (49 matches)
hibernate:
HibernateConsoleMessages.properties -
org.hibernate.eclipse.console/src/org/hibernate/eclipse/console (60 matches)
(accessor class org.hibernate.eclipse.console.HibernateConsoleMessages)
jst:
messages.properties - org.jboss.tools.jst.web/src/org/jboss/tools/jst/web/messages (29
matches)
(accessor class org.jboss.tools.jst.web.messages.xpl.WebUIMessages)
TilesEditorMessages.properties -
org.jboss.tools.jst.web.tiles.ui/src/org/jboss/tools/jst/web/tiles/ui/editor (74 matches)
vpe:
messages.properties - org.jboss.tools.vpe/src/org/jboss/tools/vpe/messages (23 matches)
(accessor class org.jboss.tools.vpe.messages.VpeUIMessages)
To get the exact list of affected strings, you will need to run Source/Find Broken
Externalized Strings against the relevant package (or your whole workspace if you like).
I'm sure a lot of these are false positives, but even so, it would be helpful to have
explanatory comments in the affected properties files. Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira