[JBoss JIRA] Created: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

[JBoss JIRA] Created: (JBIDE-4601)...

[JBoss JIRA] Created: (JBIDE-6392)...

Sean Flanigan (JIRA)

Wednesday, 18 March 2009 Wed, 18 Mar '09

3:03 a.m.

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/ -- 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

Show replies by date

Sean Flanigan (JIRA)

Wednesday, 18 March Wed, 18 Mar

3:05 a.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Sean Flanigan updated JBIDE-4044: --------------------------------- Attachment: unused_messages_in_jbosstools.zip The list of apparently unused messages.

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

-- 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

Alexey Kazakov (JIRA)

Thursday, 2 April Thu, 2 Apr

5:12 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Victor Rubezhny (JIRA)

5:27 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Victor Rubezhny (JIRA)

5:29 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Victor Rubezhny (JIRA)

6:40 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Victor Rubezhny (JIRA)

7:35 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Victor Rubezhny (JIRA)

7:47 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Sean Flanigan (JIRA)

Friday, 3 April Fri, 3 Apr

1:53 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Sean Flanigan commented on JBIDE-4044: -------------------------------------- Thanks for the work so far! Is there any sign of false positives in those places? Max suggested in the forum that there could be a lot of false positives in this list. If there's something about the JBoss Tools codebase that means Eclipse can't reliably detect unused messages (is someone using reflection on NLS/Messages classes?), I would really like to understand! I'm happy to delete these messages myself, but I first wanted to check that I wasn't making some fundamental error.

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Denny Xu (JIRA)

5:10 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Denny Xu commented on JBIDE-4044: --------------------------------- Removed unused messages from ESB and Web Service module.

...

Review unused strings from Messages classes as reported by UCDetector --------------------------------------------------------------------- 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 Reporter: Sean Flanigan 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/

Sean Flanigan (JIRA)

7:24 a.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Sean Flanigan updated JBIDE-4044: --------------------------------- Summary: Review unused strings as reported by "Find Broken Externalized Strings" (was: Review unused strings from Messages classes as reported by UCDetector) Description: 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) I'm sure a lot of these are false positives, but it would be helpful to have explanatory comments in the affected properties files. Thanks! was: 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/ Edited description to list the top seven resourcebundles according to "Find Broken Externalized Strings"

...

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 Reporter: Sean Flanigan 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) I'm sure a lot of these are false positives, but it would be helpful to have explanatory comments in the affected properties files. Thanks!

Sean Flanigan (JIRA)

7:50 a.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Sean Flanigan updated JBIDE-4044: --------------------------------- Description: 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! was: 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) I'm sure a lot of these are false positives, but it would be helpful to have explanatory comments in the affected properties files. Thanks!

...

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 Reporter: Sean Flanigan 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!

Alexey Kazakov (JIRA)

11:32 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Alexey Kazakov commented on JBIDE-4044: --------------------------------------- No sign of false positives in Seam, JSF, Struts, Common modules. We removed all mentioned unused mesages from these modules. Viktor, could you confirm that?

...

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 Reporter: Sean Flanigan 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!

Victor Rubezhny (JIRA)

2:38 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Victor Rubezhny commented on JBIDE-4044: ---------------------------------------- Thanks to Sean's fix on BrowseToTLDAttributeNameDeclaration, I can agree to Alex on Seam, JSF, JST JSP, Struts and Common modules are free of unused messages.

...

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 Reporter: Sean Flanigan 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!

Vitali Yemialyanchyk (JIRA)

4:50 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Vitali Yemialyanchyk commented on JBIDE-4044: --------------------------------------------- externalized strings was adjusted for Hibernate plugins bunch.

...

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 Reporter: Sean Flanigan 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!

Victor Rubezhny (JIRA)

6:09 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Victor Rubezhny commented on JBIDE-4044: ---------------------------------------- Unused messages are removed from JST Web and JST Web UI resource bundles. Note that in some cases the "Find Broken Externalized Strings" feature marks some messages as 'unused' while they are really used in the code. For example, RegisterServerContext or WebProjectCreationOperation bundles are marked as 'containing unused messages', while all the messages from these bundles are actually used.

...

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 Reporter: Sean Flanigan 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!

Sean Flanigan (JIRA)

Monday, 6 April Mon, 6 Apr

5:09 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

...

Note that in some cases the "Find Broken Externalized Strings" feature marks some messages as 'unused' while they are really used in the code. For example, RegisterServerContext or WebProjectCreationOperation bundles are marked as 'containing unused messages', while all the messages from these bundles are actually used.

Yes, it looks like "Find Broken Externalized Strings" gets confused when you have a real class (like a domain object) with the same basename as one of your properties files, eg RegisterServerContext and WebProjectCreationOperation. It would be good to clean these up at some point (perhaps by renaming RegisterServerContext/WebProjectCreationOperation.properties to messages.properties). "Find Broken Externalized Strings" is pretty useful, so it's probably worth a little effort to keep it happy. But this isn't urgent. Victor, do you still think TilesEditorMessages is a false positive? If so, could you please add an explanatory comment in the .properties file? jst: TilesEditorMessages.properties - org.jboss.tools.jst.web.tiles.ui/src/org/jboss/tools/jst/web/tiles/ui/editor (74 matches) To take one example, I can't find any reference to the string "TilesConfigDescriptionForm" anywhere in the codebase. I suspect some or all of the forms mentioned in this file may have been deleted. Anyone know if TilesConfigDescriptionForm, TilesDefinitionsForm, PutListsForm, etc have been deleted? Also, the accessor class TilesEditorMessages is specified in an xclass element in /org.jboss.tools.jst.web.tiles.ui/plugin.xml. I don't understand the common model, so I can't be sure, but I think TilesEditorMessages goes into a hashtable in ModelFeatureFactory, but never gets pulled out. So I don't think there are any string references through this vector. (And I assume the xclass element in plugin.xml is obsolete?) Other than TilesEditorMessages, we've still got these major offenders: 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) I can't find any sign that ArchivesUIMessages is used via reflection or concatenated property keys, so it ought be safe to delete these. Shouldn't it? common: XmlEditorMessages.properties - org.jboss.tools.common.text.xml/src/org/jboss/tools/common/text/xml/ui (49 matches) All the "unused" messages are prefixed with "XmlSyntaxPreferencePage", which I can't find anywhere else. Anything I'm missing?

...

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 Reporter: Sean Flanigan 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!

Yahor Radtsevich (JIRA)

10:52 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Yahor Radtsevich commented on JBIDE-4044: ----------------------------------------- Unused messages have been removed from *.vpe.* (JBIDE-4125: "VPE - Review externalised strings").

...

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 Reporter: Sean Flanigan 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!

Victor Rubezhny (JIRA)

5:50 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Victor Rubezhny commented on JBIDE-4044: ---------------------------------------- Sean, For the first look the TilesEditorMessages is not a "false positive". I didn't dig for *.jst.web.tiles.ui plugins (At the moment I did it only for *.jst.web and *.jst.web.ui plugins). Slava Kabanovich will clean up message bundles for *.jst.web.tiles.ui plugin as his most authority on the Tiles Editor.

...

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 Reporter: Sean Flanigan 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!

Victor Rubezhny (JIRA)

Tuesday, 7 April Tue, 7 Apr

3 p.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Victor Rubezhny commented on JBIDE-4044: ---------------------------------------- The org.jboss.tools.jst.web.ui.internal.preferences.Messages resource bundle is redeveloped to extend NLS. Un used properties are removed from the bundle.

...

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 Reporter: Sean Flanigan 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!

Rob Stryker (JIRA)

Wednesday, 8 April Wed, 8 Apr

7:45 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Rob Stryker commented on JBIDE-4044: ------------------------------------ archives / as / jmx cleared

...

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 Reporter: Sean Flanigan 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!

Max Rydahl Andersen (JIRA)

Sunday, 10 May Sun, 10 May

10:44 p.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4044: --------------------------------------- Fix Version/s: 3.1.0.M1

...

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 Fix For: 3.1.0.M1 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!

Max Rydahl Andersen (JIRA)

Tuesday, 30 June Tue, 30 Jun

1:50 p.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4044: --------------------------------------- Assignee: Sean Flanigan Sean - want to keep this open or have we reached a point where the more specific issues can be used ?

...

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!

Sean Flanigan (JIRA)

Thursday, 2 July Thu, 2 Jul

8:54 a.m.

New subject: [JBoss JIRA] Commented: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ 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!

Max Rydahl Andersen (JIRA)

8:24 p.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4044: --------------------------------------- Fix Version/s: 3.1.0.M3 (was: 3.1.0.M2) okey - so we move this to m3 (but a lot of this were done for M2)

...

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.M3 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!

Denis Golovin (JIRA)

Thursday, 20 August Thu, 20 Aug

12:24 a.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Denis Golovin updated JBIDE-4044: --------------------------------- Fix Version/s: 3.1.0.M4 (was: 3.1.0.M3)

...

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.M4 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!

Denis Golovin (JIRA)

Wednesday, 14 October Wed, 14 Oct

7:41 a.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Denis Golovin updated JBIDE-4044: --------------------------------- Fix Version/s: 3.1.0.CR1 (was: 3.1.0.M4) bulk move from M4 to CR1

...

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.CR1 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!

Max Rydahl Andersen (JIRA)

Friday, 18 December Fri, 18 Dec

6:35 p.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

...

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.GA 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!

Max Rydahl Andersen (JIRA)

Thursday, 11 February Thu, 11 Feb

6:57 p.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

...

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.1, 3.2.next 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!

Max Rydahl Andersen (JIRA)

Tuesday, 13 April Tue, 13 Apr

11:45 a.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://jira.jboss.org/jira/browse/JBIDE-4044?page=com.atlassian.jira.plu... ] Max Rydahl Andersen updated JBIDE-4044: --------------------------------------- Fix Version/s: (was: 3.1.1) lets only do this in trunk, not in maintanence.

...

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.2.next 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!

Brian Fitzpatrick (JIRA)

Thursday, 11 August Thu, 11 Aug

5:54 p.m.

New subject: [JBoss JIRA] Updated: (JBIDE-4044) Review unused strings as reported by "Find Broken Externalized Strings"

[ https://issues.jboss.org/browse/JBIDE-4044?page=com.atlassian.jira.plugin... ] Brian Fitzpatrick updated JBIDE-4044: ------------------------------------- Original Estimate: 0 minutes Remaining Estimate: 0 minutes Fix Version/s: 3.3.x (was: 3.2.x) Forum Reference: http://lists.jboss.org/pipermail/jbosstools-dev/2009-March/002909.html (was: http://lists.jboss.org/pipermail/jbosstools-dev/2009-March/002909.html)

...

Review unused strings as reported by "Find Broken Externalized Strings" ----------------------------------------------------------------------- Key: JBIDE-4044 URL: https://issues.jboss.org/browse/JBIDE-4044 Project: Tools (JBoss Tools) Issue Type: Task Components: Cleanup Affects Versions: 3.1.0.M1 Reporter: Sean Flanigan Assignee: Sean Flanigan Labels: i18n Fix For: 3.3.x Attachments: unused_messages_in_jbosstools.zip Original Estimate: 0 minutes Remaining Estimate: 0 minutes 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. For more information on JIRA, see: http://www.atlassian.com/software/jira

4707

days inactive

5583

days old

jbosstools-issues@lists.jboss.org

Manage subscription

30 comments

10 participants

tags (0)

participants (10)

Alexey Kazakov (JIRA)
Brian Fitzpatrick (JIRA)
Denis Golovin (JIRA)
Denny Xu (JIRA)
Max Rydahl Andersen (JIRA)
Rob Stryker (JIRA)
Sean Flanigan (JIRA)
Victor Rubezhny (JIRA)
Vitali Yemialyanchyk (JIRA)
Yahor Radtsevich (JIRA)

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

[JBoss JIRA] Created: (JBIDE-4044) Review unused strings from Messages classes as reported by UCDetector