Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: 3.7
-
Component/s: API, Source code viewer, Syntax Highlighter
-
Labels:None
-
Number of attachments :
Description
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this.
http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java
In addition to methods, this kind of navigation can also be applied to:
- Variable
- Types
- Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover)
- SQL tables and fields
- Labels (and their associated GO TOs)
- etc.
SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code.
Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature.
It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis.
Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code.
This knowledge should also be transfered from SSLR to Sonar.
A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML.
// Hello world method public static void foo() { System.out.println("Hello, world!"); }
could be sent to Sonar, after being analyzed by SSLR, as:
<comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); }
In the example above, the following tags were used:
- <comment>
- <keyword>
- <method>
- <link>
- <literal>
More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc.
From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly.
The details about the format are yet to be defined.
For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)?
A more compact representation could also be needed in order to limit the database storage requirement overhead.
The raw, original source code can be easily reconstructed by removing the metadata tags.
Or, we could also decide to store this additional metadata alongside the raw source code.
With the metadata, it also becomes possible to create a Javadoc perspective, to only show the Javadoc and not the source code.
Issue Links
- is depended upon by
-
SONAR-332
Publish javadoc reports
-
- is related to
-
SONAR-332
Publish javadoc reports
-
-
SONAR-4249
Highlight variable usages/declaration when clicking on its name
-
-
SONAR-4250
Highlight function usages/declaration when clicking on its name
-
- relates to
-
SONAR-675
Colorize the source code in the Resource viewer
-
-
SONAR-3893
New syntax highlighter API to not depend on sonar-channel and allow to work on multi-line tokens
-
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description | It could be useful to be able to navigate across sources as we can do with [JXR reports|http://maven.apache.org/jxr]. | It could be useful to be able to navigate across sources as we can do with [JXR reports|http://maven.apache.org/jxr] or [Clover reports|http://downloads.atlassian.com/software/clover/samples/pmd/net/sourceforge/pmd/Report.html#Report.SuppressedViolation]. |
| Fix Version/s | 3.5 [ 18825 ] |
| Link |
This issue relates to |
| Description | It could be useful to be able to navigate across sources as we can do with [JXR reports|http://maven.apache.org/jxr] or [Clover reports|http://downloads.atlassian.com/software/clover/samples/pmd/net/sourceforge/pmd/Report.html#Report.SuppressedViolation]. |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method>foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} |
| Component/s | Syntax Highlighter [ 14458 ] |
| Description |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method>foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. |
| Description |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. |
| Description |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. Or, we could also decide to store this additional metadata alongside the raw source code. |
| Description |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. Or, we could also decide to store this additional metadata alongside the raw source code. |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * Labels (and their associated GO TOs) * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. Or, we could also decide to store this additional metadata alongside the raw source code. |
| Description |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * Labels (and their associated GO TOs) * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. Or, we could also decide to store this additional metadata alongside the raw source code. |
In Eclipse, there is a feature called "Go to definition", which allows to jump from a method call directly to its definition, even if it is in another file.
Some online source code viewer, such as GrepCode, also implement this. http://grepcode.com/file/repo1.maven.org/maven2/commons-lang/commons-lang/2.3/org/apache/commons/lang/math/NumberUtils.java In addition to methods, this kind of navigation can also be applied to: * Variable * Types * Macros (C preprocessor) (and possibly show their expanded versions upon mouse hover) * SQL tables and fields * Labels (and their associated GO TOs) * etc. SSLR, which is used in most of our language plugins during the batch analysis, knows exactly what are the variables, types, macro expansions, SQL tables, and so forth, referenced in the source code. Moreover, it also knows where those variables, types, macros, etc. were defined, thanks to its symbol table feature. It therefore seems natural that SSLR would somehow transfer this knowledge to Sonar during the analysis. Moreover, SSLR also knows what were the Javadoc, XML comments (.NET's equivalent to the Javadoc), basic comments, keywords, string literals, variable names, etc. which were found in the source code. This knowledge should also be transfered from SSLR to Sonar. A possible way to implement this would be to annotate the original source code with some metadata, for example using a kind of XML. {code} // Hello world method public static void foo() { System.out.println("Hello, world!"); } {code} could be sent to Sonar, after being analyzed by SSLR, as: {code} <comment>// Hello world method</comment> <keyword>public</keyword> <keyword>static</keyword> <keyword>void</keyword> <method signature="org.example.MyClass.foo()">foo</method>() { <link kind="type" ref="java.lang.System">System</link>.<link kind="field" ref="java.lang.System.out">out</link>.<link kind="method" ref="java.io.PrintStream.println(String)">println</link>(<literal>"Hello, world!"</literal>); } {code} In the example above, the following tags were used: * <comment> * <keyword> * <method> * <link> * <literal> More tags could be required, for example to handle conditional compilation, code margins (PL/I and COBOL), preprocessing directives, etc. From there, Sonar should be able to generate the links on the fly to enable the navigation, and also to highlight the source code properly. The details about the format are yet to be defined. For example, should SSLR tell Sonar which resource key to open and at which line, or should it tell Sonar to open a method with a given signature (as shown in the example)? A more compact representation could also be needed in order to limit the database storage requirement overhead. The raw, original source code can be easily reconstructed by removing the metadata tags. Or, we could also decide to store this additional metadata alongside the raw source code. With the metadata, it also becomes possible to create a Javadoc perspective, to only show the Javadoc and not the source code. |
| Fix Version/s | 3.6 [ 19016 ] | |
| Fix Version/s | 3.5 [ 18825 ] |
| Assignee | Jean-Baptiste Vilain [ jeanbaptiste ] |
| Component/s | API [ 13360 ] |
| Assignee | Jean-Baptiste Vilain [ jeanbaptiste ] | |
| Fix Version/s | 3.7 [ 19107 ] | |
| Fix Version/s | 3.6 [ 19016 ] |
| Link |
This issue is related to |
| Link |
This issue is related to |