[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans IDE
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Summary: Using groovy compiler for parsing, code completion and navigation in NetBeans IDE (was: Using groovy compiler for parsing, code completion and navigation in NetBeans) > Using groovy compiler for parsing, code completion and navigation in NetBeans > IDE > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of writing Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. In particular the IDE has to be > able to deal with broken code (user code in editor is broken most of the > time) - as such we expect fixes in the area of error recovery to make the > parser more bulletproof and robust. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present them to the user in a reasonable and > valuable way. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of writing Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. In particular the IDE has to be able to deal with broken code (user code in editor is broken most of the time) - as such we expect fixes in the area of error recovery to make the parser more bulletproof and robust. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. In particular the IDE has to be able to deal with broken code (user code in editor is broken most of the time) - as such we expect fixes in the area of error recovery to make the parser more bulletproof and robust. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of writing Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. In particular the IDE has to be > able to deal with
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. In particular the IDE has to be able to deal with broken code (user code in editor is broken most of the time) - as such we expect fixes in the area of error recovery to make the parser more bulletproof and robust. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. In particular the IDE has to be > able to deal with broken code (user code in editor is broken most of the > time) - as such we expect fixes in the area of error recovery to make the > parser more bulletproof and robust. > Some of the reported issues may feel
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present them to the user in a reasonable and valuable way. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present them to the user in a reasonable and > valuable way. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE (and its derivatives like VSCode) better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE (and its derivatives like VSCode) better, richer, easier to use, faster > to gain response and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute the IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute the IDE related fixes to > the Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail:
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it turns on the > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real compiler allowed > NetBeans to keep the WYSIWYG experience (the errors reported in the editor > are exactly the same as on command line or continuous integration) with > relatively low effort. However maintaining a fork turned out to be costly and > we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to > do even better. We want to contribute IDE related fixes to the Groovy > compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the WYSIWYG experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute IDE related fixes to the > Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. was: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real Java compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it uses type checking and static compilation heavily. It would be ideal if the IDE could just use the static compilation info/errors and present it to the user. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real Java compiler > allowed NetBeans to keep the *WYSIWYG* experience (the errors reported in the > editor are exactly the same as on command line or continuous integration) > with relatively low effort. However maintaining a fork turned out to be > costly and we are looking forward to reuse *javac* unmodified. With Groovy, > we'd like to do even better. We want to contribute IDE related fixes to the > Groovy compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it uses type checking and static > compilation heavily. It would be ideal if the IDE could just use the static > compilation info/errors and present it to the user. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Description: NetBeans IDE has a tradition of using the real compiler for each language to provide the best user experience in its editor. A famous example is [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] - NetBeans fork of the *javac* compiler. Using the real compiler allowed NetBeans to keep the WYSIWYG experience (the errors reported in the editor are exactly the same as on command line or continuous integration) with relatively low effort. However maintaining a fork turned out to be costly and we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to do even better. We want to contribute IDE related fixes to the Groovy compiler to begin with! This issue is an umbrella collecting various issues filed against Groovy. Fixing them would make the user experience of using of Groovy in the NetBeans IDE and derivatives better, richer, easier to use, faster to gain response and overall more reliable. Some of the reported issues may feel strange from a plain Groovy point of view. Please take into account that the IDE needs to compute all the info without running the user code. As such it turns on the was: Umbrella issue, that could help to collect dependent errors filed in Groovy. Maybe it could be split to an issue tracking possible improvements and an issue that tracks improvment necessary for the next release. > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > NetBeans IDE has a tradition of using the real compiler for each language to > provide the best user experience in its editor. A famous example is > [nb-javac|https://cwiki.apache.org/confluence/display/NETBEANS/Overview%3A+nb-javac] > - NetBeans fork of the *javac* compiler. Using the real compiler allowed > NetBeans to keep the WYSIWYG experience (the errors reported in the editor > are exactly the same as on command line or continuous integration) with > relatively low effort. However maintaining a fork turned out to be costly and > we are looking forward to reuse *javac* unmodified. With Groovy, we'd like to > do even better. We want to contribute IDE related fixes to the Groovy > compiler to begin with! > This issue is an umbrella collecting various issues filed against Groovy. > Fixing them would make the user experience of using of Groovy in the NetBeans > IDE and derivatives better, richer, easier to use, faster to gain response > and overall more reliable. > Some of the reported issues may feel strange from a plain Groovy point of > view. Please take into account that the IDE needs to compute all the info > without running the user code. As such it turns on the -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-5992) Using groovy compiler for parsing, code completion and navigation in NetBeans
[ https://issues.apache.org/jira/browse/NETBEANS-5992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaroslav Tulach updated NETBEANS-5992: -- Summary: Using groovy compiler for parsing, code completion and navigation in NetBeans (was: Groovy compiler / parser bugs affecting NB code completion) > Using groovy compiler for parsing, code completion and navigation in NetBeans > - > > Key: NETBEANS-5992 > URL: https://issues.apache.org/jira/browse/NETBEANS-5992 > Project: NetBeans > Issue Type: Task > Components: groovy - Editor >Reporter: Svatopluk Dedic >Assignee: Svatopluk Dedic >Priority: Major > > Umbrella issue, that could help to collect dependent errors filed in Groovy. > Maybe it could be split to an issue tracking possible improvements and an > issue that tracks improvment necessary for the next release. > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
