[jira] [Commented] (NETBEANS-4203) org.netbeans.api.io.InputOutput.reset() doesn't work
[
https://issues.apache.org/jira/browse/NETBEANS-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092037#comment-17092037
]
Ernie Rael commented on NETBEANS-4203:
--
This latest module has 3 tests with increased verification; the tests report
pass/fail. It installs 4 Menu items at the top of tools list like:
---
Run All Tests
---
Input Output Reset Test
Multiple Input Output
Two Task Reset
---
Run All Tests runs each of the three tests.
> org.netbeans.api.io.InputOutput.reset() doesn't work
>
>
> Key: NETBEANS-4203
> URL: https://issues.apache.org/jira/browse/NETBEANS-4203
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Output Window
>Reporter: Ernie Rael
>Priority: Major
> Attachments: InputOutputReset.jar, InputOutputReset.jar
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test module is attached. The module installs an action "Tools > Input
> OutputReset Test"
> This test is taken verbatim from the _I/O API SPI Overview_, it is UseCase5:
>
> [https://bits.netbeans.org/dev/javadoc/org-netbeans-api-io/overview-summary.html]
> with the "io.show()" added to simplify the observation of the failure.
> After running the test, the output window should only have
> {code:java}
> The pane is now empty and we can reuse it simply
> {code}
> It doesn't; in addition the data from before the "reset()" is still there.
--
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-4241) Refactoring results in java.util.ConcurrentModificationException
[ https://issues.apache.org/jira/browse/NETBEANS-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Davie updated NETBEANS-4241: -- Attachment: messages.log > Refactoring results in java.util.ConcurrentModificationException > > > Key: NETBEANS-4241 > URL: https://issues.apache.org/jira/browse/NETBEANS-4241 > Project: NetBeans > Issue Type: Bug > Components: editor - Refactoring >Affects Versions: 11.2 >Reporter: Peter Davie >Priority: Major > Attachments: messages.log > > > Refactoring periodically generates a > java.util.ConcurrentModificationException. Sometimes cancelling and > repeating the refactoring will be performed cleanly. > Exact message is: > Module Java Refactoring threw java.util.ConcurrentModificationException. > Please report a bug against Java Refactoring module and attach your > var/log/messages.log. -- 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] [Created] (NETBEANS-4241) Refactoring results in java.util.ConcurrentModificationException
Peter Davie created NETBEANS-4241: - Summary: Refactoring results in java.util.ConcurrentModificationException Key: NETBEANS-4241 URL: https://issues.apache.org/jira/browse/NETBEANS-4241 Project: NetBeans Issue Type: Bug Components: editor - Refactoring Affects Versions: 11.2 Reporter: Peter Davie Refactoring periodically generates a java.util.ConcurrentModificationException. Sometimes cancelling and repeating the refactoring will be performed cleanly. Exact message is: Module Java Refactoring threw java.util.ConcurrentModificationException. Please report a bug against Java Refactoring module and attach your var/log/messages.log. -- 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-4203) org.netbeans.api.io.InputOutput.reset() doesn't work
[
https://issues.apache.org/jira/browse/NETBEANS-4203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernie Rael updated NETBEANS-4203:
-
Attachment: InputOutputReset.jar
> org.netbeans.api.io.InputOutput.reset() doesn't work
>
>
> Key: NETBEANS-4203
> URL: https://issues.apache.org/jira/browse/NETBEANS-4203
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Output Window
>Reporter: Ernie Rael
>Priority: Major
> Attachments: InputOutputReset.jar, InputOutputReset.jar
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test module is attached. The module installs an action "Tools > Input
> OutputReset Test"
> This test is taken verbatim from the _I/O API SPI Overview_, it is UseCase5:
>
> [https://bits.netbeans.org/dev/javadoc/org-netbeans-api-io/overview-summary.html]
> with the "io.show()" added to simplify the observation of the failure.
> After running the test, the output window should only have
> {code:java}
> The pane is now empty and we can reuse it simply
> {code}
> It doesn't; in addition the data from before the "reset()" is still there.
--
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] [Commented] (NETBEANS-1521) Analyze Performance - Root Methods test case fails at step 3
[ https://issues.apache.org/jira/browse/NETBEANS-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17092034#comment-17092034 ] Manikantan Narender Nath commented on NETBEANS-1521: Reproduced in ** *Product Version:* Apache NetBeans IDE 12.0-beta3 *Java:* 11.0.6; OpenJDK 64-Bit Server VM 11.0.6+10 *Runtime:* OpenJDK Runtime Environment 11.0.6+10 *System:* Mac OS X version 10.15.3 running on x86_64; UTF-8; en_IN (nb) > Analyze Performance - Root Methods test case fails at step 3 > > > Key: NETBEANS-1521 > URL: https://issues.apache.org/jira/browse/NETBEANS-1521 > Project: NetBeans > Issue Type: Bug > Components: profiler - Base, profiler - Engine, profiler - IDE >Affects Versions: 10.0 > Environment: MacOSX > JDK 11 >Reporter: John Kostaras >Priority: Minor > Attachments: method-guessedWordActionPerformed-not-found.png > > > Test case "Analyze Performance - Root Methods" fails at step 3. -- 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-1521) Analyze Performance - Root Methods test case fails at step 3
[ https://issues.apache.org/jira/browse/NETBEANS-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manikantan Narender Nath updated NETBEANS-1521: --- Attachment: method-guessedWordActionPerformed-not-found.png > Analyze Performance - Root Methods test case fails at step 3 > > > Key: NETBEANS-1521 > URL: https://issues.apache.org/jira/browse/NETBEANS-1521 > Project: NetBeans > Issue Type: Bug > Components: profiler - Base, profiler - Engine, profiler - IDE >Affects Versions: 10.0 > Environment: MacOSX > JDK 11 >Reporter: John Kostaras >Priority: Minor > Attachments: method-guessedWordActionPerformed-not-found.png > > > Test case "Analyze Performance - Root Methods" fails at step 3. -- 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-4240) Extract Interface refactoring produces exception
[
https://issues.apache.org/jira/browse/NETBEANS-4240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Davie updated NETBEANS-4240:
--
Attachment: messages.log.1
> Extract Interface refactoring produces exception
>
>
> Key: NETBEANS-4240
> URL: https://issues.apache.org/jira/browse/NETBEANS-4240
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Refactoring
>Affects Versions: 11.2
> Environment: Product Version: Apache NetBeans IDE 11.2
> Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
> Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9
> Runtime: OpenJDK Runtime Environment 11.0.2+9
> System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
>Reporter: Peter Davie
>Priority: Major
> Attachments: messages.log.1
>
>
> {color:#172b4d}Attempted to extract an interface from an existing (abstract)
> class and the following exception was reported.{color}
> {color:#FF}Warning: {color}Module Java Refactoring threw
> java.lang.IllegalStateException: Cannot call getCompilationUnit() if current
> phase JavaSource.Phase.PARSED. You must call toPhase(Phase.PARSED) first..
> Please report a bug against Java Refactoring module and attach your
> var/log/messages.log.
> I don't know if it's relevant, but the class concerned has a spurious error
> reported about it being a JPA Entity class with no ID associated, it has an
> Id annotation defined on the identifier member field (but the error is
> reported in the editor, even though the code compiles correctly).
>
--
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] [Created] (NETBEANS-4240) Extract Interface refactoring produces exception
Peter Davie created NETBEANS-4240:
-
Summary: Extract Interface refactoring produces exception
Key: NETBEANS-4240
URL: https://issues.apache.org/jira/browse/NETBEANS-4240
Project: NetBeans
Issue Type: Bug
Components: editor - Refactoring
Affects Versions: 11.2
Environment: Product Version: Apache NetBeans IDE 11.2
Updates: NetBeans IDE is updated to version NetBeans 8.2 Patch 2
Java: 11.0.2; OpenJDK 64-Bit Server VM 11.0.2+9
Runtime: OpenJDK Runtime Environment 11.0.2+9
System: Windows 10 version 10.0 running on amd64; Cp1252; en_AU (nb)
Reporter: Peter Davie
{color:#172b4d}Attempted to extract an interface from an existing (abstract)
class and the following exception was reported.{color}
{color:#FF}Warning: {color}Module Java Refactoring threw
java.lang.IllegalStateException: Cannot call getCompilationUnit() if current
phase JavaSource.Phase.PARSED. You must call toPhase(Phase.PARSED) first..
Please report a bug against Java Refactoring module and attach your
var/log/messages.log.
I don't know if it's relevant, but the class concerned has a spurious error
reported about it being a JPA Entity class with no ID associated, it has an Id
annotation defined on the identifier member field (but the error is reported in
the editor, even though the code compiles correctly).
--
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-4239) no code assistance in *.jsp files
[ https://issues.apache.org/jira/browse/NETBEANS-4239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nils Huhta updated NETBEANS-4239: - Attachment: Maven_vs_Gradle.jpg > no code assistance in *.jsp files > - > > Key: NETBEANS-4239 > URL: https://issues.apache.org/jira/browse/NETBEANS-4239 > Project: NetBeans > Issue Type: Task > Components: projects - Gradle Java EE >Affects Versions: 11.3 >Reporter: Nils Huhta >Assignee: Laszlo Kishalmi >Priority: Major > Attachments: Maven_vs_Gradle.jpg > > > When editing JSP files in a Gradle Java EE Web application project, no code > assistance, for example code below gives no error > <% int one number = "xxx"; %> > In same Netbeans version a Maven Web application with jsp files works as > expected... -- 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] [Created] (NETBEANS-4239) no code assistance in *.jsp files
Nils Huhta created NETBEANS-4239: Summary: no code assistance in *.jsp files Key: NETBEANS-4239 URL: https://issues.apache.org/jira/browse/NETBEANS-4239 Project: NetBeans Issue Type: Task Components: projects - Gradle Java EE Affects Versions: 11.3 Reporter: Nils Huhta Assignee: Laszlo Kishalmi When editing JSP files in a Gradle Java EE Web application project, no code assistance, for example code below gives no error <% int one number = "xxx"; %> In same Netbeans version a Maven Web application with jsp files works as expected... -- 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] [Closed] (NETBEANSINFRA-185) Register PP3 UC in Apache NetBeans 12.0
[ https://issues.apache.org/jira/browse/NETBEANSINFRA-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiří Kovalský closed NETBEANSINFRA-185. --- Resolution: Fixed Merged: https://github.com/apache/netbeans-website/pull/469 > Register PP3 UC in Apache NetBeans 12.0 > --- > > Key: NETBEANSINFRA-185 > URL: https://issues.apache.org/jira/browse/NETBEANSINFRA-185 > Project: Apache NetBeans Infra > Issue Type: Task > Components: PluginPortal - infra >Reporter: Jiří Kovalský >Assignee: Antonio Vieiro >Priority: Critical > > We need to register update center [1] of new Plugin Portal 3.0 in the Apache > NetBeans IDE 12.0 and either remove or rename the old one [2] to Legacy > Plugin Portal. > [1] [https://plugins.netbeans.apache.org/data/12.0/catalog.xml.gz] > [2] > [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz|http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml] -- 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
[netbeans-website] branch master updated (b145309 -> 69f5ebc)
This is an automated email from the ASF dual-hosted git repository. jkovalsky pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-website.git. from b145309 Update nb113.asciidoc add 447f468 Changing location of Plugin Portal Update Center for NetBeans 12.0 new 69f5ebc Merge pull request #469 from apache/jkovalsky/newPPUC The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: netbeans.apache.org/src/content/.htaccess | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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
[netbeans-website] 01/01: Merge pull request #469 from apache/jkovalsky/newPPUC
This is an automated email from the ASF dual-hosted git repository. jkovalsky pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-website.git commit 69f5ebc8f305c364d70294b81d66f18b409407b0 Merge: b145309 447f468 Author: Jiří Kovalský <32838335+jkoval...@users.noreply.github.com> AuthorDate: Fri Apr 24 20:31:06 2020 +0200 Merge pull request #469 from apache/jkovalsky/newPPUC Thank you guys. Rest in peace Plugin Portal 2.0. Long live Plugin Portal 3.0! netbeans.apache.org/src/content/.htaccess | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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] [Commented] (NETBEANS-2440) Cannot Debug Focused Test Method with project created by Netbean 8.2 in Netbean 11
[ https://issues.apache.org/jira/browse/NETBEANS-2440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091689#comment-17091689 ] Paul commented on NETBEANS-2440: I can confirm that adding the debug-single-method above fixes the problem? Can we get this sorted out on future updates so we don't need to hack in on new projects? > Cannot Debug Focused Test Method with project created by Netbean 8.2 in > Netbean 11 > -- > > Key: NETBEANS-2440 > URL: https://issues.apache.org/jira/browse/NETBEANS-2440 > Project: NetBeans > Issue Type: Bug >Affects Versions: 8.2, 11.0 >Reporter: Thai Thien >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > How to reproduce: > # Create project with Netbean 8.2 > # Create test method in Netbean 8.2 (right click -> Tools -> create/update > tests) > # Select (highlight) a method in test, right click -> Debug Focused Test > Method. Make sure it can run with Netbean 8.2 > # Close Netbean 8.2 > # Open project with Netbean 11.0 > # Select (highlight) a method in test, right click -> Debug Focused Test > Method. Make sure it can run with Netbean 8.2 > # it show error > Target "debug-single-method" does not exist in the project "your project name" -- 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-4238) Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10)
[ https://issues.apache.org/jira/browse/NETBEANS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4238: -- Description: This issue created from an email on the nbusers list. Thomas Kellerer writes: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem [attached to JIRA issue here] I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. was: This issue created from an email on the nbusers list. Thomas Kellerer writes: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. > Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10) > > > Key: NETBEANS-4238 > URL: https://issues.apache.org/jira/browse/NETBEANS-4238 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 11.3 > Environment: This happens both in 11.3 and 12-beta3. I am using > Windows 10, and this is not a High-DPI display (standard 1920*1200 monitor). >Reporter: Eirik Bakke >Priority: Minor > Attachments: umlauts.png > > > This issue created from an email on the nbusers list. Thomas Kellerer writes: > I am using the (built-in) Consolas font for editing in NetBeans (and all > other code editors actually). > It seems that the line height in the NetBeans editor is a bit too small and > cuts off the top most pixels. > This isn't really a problem, except for upper case German umlauts (ÖÄÜ). > However the output window (using the same font) does not suffer from this. > I have uploaded a screenshot to show the problem [attached to JIRA issue here] > I remember in very old NetBeans versions it was possible to influence the > line height in the editor, but apparently this isn't possible any more. > Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case > with 11 as well. -- 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-4238) Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10)
[ https://issues.apache.org/jira/browse/NETBEANS-4238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eirik Bakke updated NETBEANS-4238: -- Description: This issue created from an email on the nbusers list. Thomas Kellerer writes: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. was: I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. > Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10) > > > Key: NETBEANS-4238 > URL: https://issues.apache.org/jira/browse/NETBEANS-4238 > Project: NetBeans > Issue Type: Bug > Components: editor - Painting Printing >Affects Versions: 11.3 > Environment: This happens both in 11.3 and 12-beta3. I am using > Windows 10, and this is not a High-DPI display (standard 1920*1200 monitor). >Reporter: Eirik Bakke >Priority: Minor > Attachments: umlauts.png > > > This issue created from an email on the nbusers list. Thomas Kellerer writes: > I am using the (built-in) Consolas font for editing in NetBeans (and all > other code editors actually). > It seems that the line height in the NetBeans editor is a bit too small and > cuts off the top most pixels. > This isn't really a problem, except for upper case German umlauts (ÖÄÜ). > However the output window (using the same font) does not suffer from this. > I have uploaded a screenshot to show the problem: > https://i.imgur.com/g8gGvLK.png > I remember in very old NetBeans versions it was possible to influence the > line height in the editor, but apparently this isn't possible any more. > Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case > with 11 as well. -- 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] [Created] (NETBEANS-4238) Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10)
Eirik Bakke created NETBEANS-4238: - Summary: Umlauts (ÖÄÜ...) invisible in editor with Consolas font (Windows 10) Key: NETBEANS-4238 URL: https://issues.apache.org/jira/browse/NETBEANS-4238 Project: NetBeans Issue Type: Bug Components: editor - Painting Printing Affects Versions: 11.3 Environment: This happens both in 11.3 and 12-beta3. I am using Windows 10, and this is not a High-DPI display (standard 1920*1200 monitor). Reporter: Eirik Bakke Attachments: umlauts.png I am using the (built-in) Consolas font for editing in NetBeans (and all other code editors actually). It seems that the line height in the NetBeans editor is a bit too small and cuts off the top most pixels. This isn't really a problem, except for upper case German umlauts (ÖÄÜ). However the output window (using the same font) does not suffer from this. I have uploaded a screenshot to show the problem: https://i.imgur.com/g8gGvLK.png I remember in very old NetBeans versions it was possible to influence the line height in the editor, but apparently this isn't possible any more. Currently I run NetBeans with AdoptOpenJDK 13, but this was already the case with 11 as well. -- 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] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091584#comment-17091584
]
Geertjan Wielenga commented on NETBEANS-4222:
-
Starting point would be to start a discussion on the dev mailing list with your
ideas, keep it as concise and focused as you can.
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091581#comment-17091581
]
Markus Sunela commented on NETBEANS-4222:
-
Cool, thanks Geertjan! That sounds viable and probably much less invasive
approach. Still, there are be many more locations besides the ProxyNode, where
being able to change or extend the functionality would be worthwhile, but let's
start with a thing at a time.
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[ https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091565#comment-17091565 ] Markus Sunela edited comment on NETBEANS-4222 at 4/24/20, 1:34 PM: --- Thanks for the comments and the book links. They're good read! You have all the freedom and rights to not to accept the patch, and your reasons are much more well thought and better founded than mine. Good API design of course is hard and delicate work, and I am not qualified to argue that and the long experience of you both working with NetBeans platform. What I am putting forward is a suggestion. Personally, I just don't see value in making and keeping API closed down just because it is considered good design, when it severely limits the future possibilities what could be achieved using and extending the classes that are already there. Documenting the opened APIs is easy enough and no, I am not proposing any changes without test coverage and or versioning. The pull request was just an answer to Geertjan's idea to "make the changes yourself" - here are the changes. Creating the tests, documentation and all would be wasted, if there wouldn't be any interest in the changes. In my opinion any specific use-cases are not that matters, when the problem is overall API rigidity (which is, I guess, at least in part subjective notion), but if you need some use-cases, here's the acute one I am trying to solve: being able to replace ProxyNode usage in PropertySheet with more efficient implementation, that can ignore most of the properties and tabs and that can properly cache available properties based on the common base class of the (Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes being edited and once, and the performance starts to be very poor. As PropertySheet.doSetNodes is private and the method is called from many more private functions and classes, there is no way how I could override that. I cannot also create my own PropertySheet copy, as it again depends on many package private classes and so on. Creating a separate copy of whole org.openide.nodes and org.openide.explorer modules seems so wasteful just to change one method. That's why I would like to argue, that the whole API could be made more flexible to begin with, as there would be many other. was (Author: markus.sun...@fluidit.fi): Thanks for the comments and the book links. They're good read! You have all the freedom and rights to not to accept the patch, and your reasons are much more well thought and better founded than mine. Good API design of course is hard and delicate work, and I am not qualified to argue that and the long experience of you both working with NetBeans platform. What I am putting forward is a suggestion. Personally, I just don't see value in making and keeping API closed down just because it is considered good design, when it severely limits the future possibilities what could be achieved using and extending the classes that are already there. Documenting the opened APIs is easy enough and no, I am not proposing any changes without test coverage and or versioning. The pull request was just an answer to Geertjan's idea to "make the changes yourself" - here are the changes. Creating the tests, documentation and all would be wasted, if there wouldn't be any interested in the changes. In my opinion any specific use-cases are not that matters, when the problem is overall API rigidity (which is, I guess, at least in part subjective notion), but if you some use-cases, here's the acute one I am trying to solve: being able to replace ProxyNode usage in PropertySheet with more efficient implementation, that can ignore most of the properties and tabs and that can properly cache available properties based on the common base class of the (Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes being edited and once, and the performance starts to be very poor. As PropertySheet.doSetNodes is private and the method is called from many more private functions and classes, there is no way how I could override that. I cannot also create my own PropertySheet copy, as it again depends on many package private classes and so on. Creating a separate copy of whole org.openide.nodes and org.openide.explorer modules seems so wasteful just to change one method. That's why I would like to argue, that the whole API could be made more flexible to begin with, as there would be many other. > Open up more of APIs in Node and PropertySheet > -- > > Key: NETBEANS-4222 > URL: https://issues.apache.org/jira/browse/NETBEANS-4222 > Project: NetBeans > Issue Type: Improvement > Components: platform - Explorer, platform - Nodes >Reporter: Markus Sunela
[jira] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:26 PM:
---
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"Being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
Maybe the solution here is to not try to open the API, but to make these
changes in the Properties infrastructure and provide that as a pull request?
I.e., don't aim to replace ProxyNode, but instead aim to rewrite it, after
discussing your requirements in detail on the dev mailing list?
was (Author: geertjanwielenga):
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"Being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
Maybe the solution here is to not try to open the API, but to make these
changes in the Properties infrastructure and provide that as a pull request?
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:25 PM:
---
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"Being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
Maybe the solution here is to not try to open the API, but to make these
changes in the Properties infrastructure and provide that as a pull request?
was (Author: geertjanwielenga):
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"Being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:24 PM:
---
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"Being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
was (Author: geertjanwielenga):
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:23 PM:
---
You were really planning to provide no motivation up front, no use cases, no
API change discussion... really? Is that also how you do API changes for your
own software?
OK, this is it, [~jtulach], what do you think:
"being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
was (Author: geertjanwielenga):
You were really planning to provide no motivation up front, no use cases, no
API change discussion... really? Is that also how you do API changes for your
own software?
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:23 PM:
---
OK, this is it, the use case, from the above, [~jtulach], what do you think:
"being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
was (Author: geertjanwielenga):
You were really planning to provide no motivation up front, no use cases, no
API change discussion... really? Is that also how you do API changes for your
own software?
OK, this is it, [~jtulach], what do you think:
"being able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other."
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:22 PM:
---
You were really planning to provide no motivation up front, no use cases, no
API change discussion... really? Is that also how you do API changes for your
own software?
was (Author: geertjanwielenga):
You were really planning to provide no motivation up front, no API change
discussion... really? Is that also how you do API changes for your own software?
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga edited comment on NETBEANS-4222 at 4/24/20, 1:21 PM:
---
You were really planning to provide no motivation up front, no API change
discussion... really? Is that also how you do API changes for your own software?
was (Author: geertjanwielenga):
You were really planning to provide no motivation, no use cases, no tests, no
API change discusion... really? Is that also how you do API changes for your
own software?
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091570#comment-17091570
]
Geertjan Wielenga commented on NETBEANS-4222:
-
You were really planning to provide no motivation, no use cases, no tests, no
API change discusion... really? Is that also how you do API changes for your
own software?
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Comment Edited] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[ https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091565#comment-17091565 ] Markus Sunela edited comment on NETBEANS-4222 at 4/24/20, 1:17 PM: --- Thanks for the comments and the book links. They're good read! You have all the freedom and rights to not to accept the patch, and your reasons are much more well thought and better founded than mine. Good API design of course is hard and delicate work, and I am not qualified to argue that and the long experience of you both working with NetBeans platform. What I am putting forward is a suggestion. Personally, I just don't see value in making and keeping API closed down just because it is considered good design, when it severely limits the future possibilities what could be achieved using and extending the classes that are already there. Documenting the opened APIs is easy enough and no, I am not proposing any changes without test coverage and or versioning. The pull request was just an answer to Geertjan's idea to "make the changes yourself" - here are the changes. Creating the tests, documentation and all would be wasted, if there wouldn't be any interested in the changes. In my opinion any specific use-cases are not that matters, when the problem is overall API rigidity (which is, I guess, at least in part subjective notion), but if you some use-cases, here's the acute one I am trying to solve: being able to replace ProxyNode usage in PropertySheet with more efficient implementation, that can ignore most of the properties and tabs and that can properly cache available properties based on the common base class of the (Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes being edited and once, and the performance starts to be very poor. As PropertySheet.doSetNodes is private and the method is called from many more private functions and classes, there is no way how I could override that. I cannot also create my own PropertySheet copy, as it again depends on many package private classes and so on. Creating a separate copy of whole org.openide.nodes and org.openide.explorer modules seems so wasteful just to change one method. That's why I would like to argue, that the whole API could be made more flexible to begin with, as there would be many other. was (Author: markus.sun...@fluidit.fi): You have all the freedom and rights to not to accept the patch, and your reasons are much more well thought and better founded than mine. Good API design of course is hard and delicate work, and I am not qualified to argue that and the long experience of you both working with NetBeans platform. What I am putting forward is a suggestion. Personally, I just don't see value in making and keeping API closed down just because it is considered good design, when it severely limits the future possibilities what could be achieved using and extending the classes that are already there. Documenting the opened APIs is easy enough and no, I am not proposing any changes without test coverage and or versioning. The pull request was just an answer to Geertjan's idea to "make the changes yourself" - here are the changes. Creating the tests, documentation and all would be wasted, if there wouldn't be any interested in the changes. In my opinion any specific use-cases are not that matters, when the problem is overall API rigidity (which is, I guess, at least in part subjective notion), but if you some use-cases, here's the acute one I am trying to solve: being able to replace ProxyNode usage in PropertySheet with more efficient implementation, that can ignore most of the properties and tabs and that can properly cache available properties based on the common base class of the (Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes being edited and once, and the performance starts to be very poor. As PropertySheet.doSetNodes is private and the method is called from many more private functions and classes, there is no way how I could override that. I cannot also create my own PropertySheet copy, as it again depends on many package private classes and so on. Creating a separate copy of whole org.openide.nodes and org.openide.explorer modules seems so wasteful just to change one method. That's why I would like to argue, that the whole API could be made more flexible to begin with, as there would be many other. > Open up more of APIs in Node and PropertySheet > -- > > Key: NETBEANS-4222 > URL: https://issues.apache.org/jira/browse/NETBEANS-4222 > Project: NetBeans > Issue Type: Improvement > Components: platform - Explorer, platform - Nodes >Reporter: Markus Sunela >Priority: Minor > > Currently it is hard to customize
[jira] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091565#comment-17091565
]
Markus Sunela commented on NETBEANS-4222:
-
You have all the freedom and rights to not to accept the patch, and your
reasons are much more well thought and better founded than mine. Good API
design of course is hard and delicate work, and I am not qualified to argue
that and the long experience of you both working with NetBeans platform. What I
am putting forward is a suggestion.
Personally, I just don't see value in making and keeping API closed down just
because it is considered good design, when it severely limits the future
possibilities what could be achieved using and extending the classes that are
already there. Documenting the opened APIs is easy enough and no, I am not
proposing any changes without test coverage and or versioning. The pull request
was just an answer to Geertjan's idea to "make the changes yourself" - here are
the changes. Creating the tests, documentation and all would be wasted, if
there wouldn't be any interested in the changes.
In my opinion any specific use-cases are not that matters, when the problem is
overall API rigidity (which is, I guess, at least in part subjective notion),
but if you some use-cases, here's the acute one I am trying to solve: being
able to replace ProxyNode usage in PropertySheet with more efficient
implementation, that can ignore most of the properties and tabs and that can
properly cache available properties based on the common base class of the
(Bean)Nodes passed to it. We can have thousands to tens of thousands of nodes
being edited and once, and the performance starts to be very poor. As
PropertySheet.doSetNodes is private and the method is called from many more
private functions and classes, there is no way how I could override that. I
cannot also create my own PropertySheet copy, as it again depends on many
package private classes and so on. Creating a separate copy of whole
org.openide.nodes and org.openide.explorer modules seems so wasteful just to
change one method. That's why I would like to argue, that the whole API could
be made more flexible to begin with, as there would be many other.
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Commented] (NETBEANS-4222) Open up more of APIs in Node and PropertySheet
[
https://issues.apache.org/jira/browse/NETBEANS-4222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091530#comment-17091530
]
Jaroslav Tulach commented on NETBEANS-4222:
---
I tried to summarize the rationale in my [Practical API
Design|http://practical.apidesign.org/] book. There is even a story where a
colleague of mine wanted to make {{Node.getChildren()}} method overridable in
subclasses and why it is still {{final}}. In short: there has to be a balance
between freedom of API users and freedom of API maintainers. Btw. there is a
[freedom chapter in the 20 API Paradoxes e-book|http://buy.apidesign.org/].
Chapter 16 of the [Practical API Design|http://practical.apidesign.org/] book
contains a section _"Accepting API Patches"_. Reading it I can say that your
proposal removes our freedom because:
* Your patch restricts future evolution
* You have provided completely underdocumented patch
** the classes/methods you make public aren't document
** but worse: the overall use-case isn't explained
* You want to make API changes without any test coverage
* You API changes aren't versioned
I am not convinced it is enough justified to give up the NetBeans API evolution
freedom by accepting your changes at current state.
> Open up more of APIs in Node and PropertySheet
> --
>
> Key: NETBEANS-4222
> URL: https://issues.apache.org/jira/browse/NETBEANS-4222
> Project: NetBeans
> Issue Type: Improvement
> Components: platform - Explorer, platform - Nodes
>Reporter: Markus Sunela
>Priority: Minor
>
> Currently it is hard to customize Node, Explorer and PropertySheet behavior,
> because there are too many private instead of protected methods, package
> private and final classes in the API.
> Some examples I have stumbled on include
> * private doSetNodes method in PropertySheet (no way to override the use of
> ProxyNodes)
> * final and package private ProxyNode class
> * package private constructor in ProxyNode
> * package private getOriginalNodes method in ProxyNode
> * package private and final {color:#00}ProxyProperty{color} class in
> ProxyNode
> * final Sheet class and its inner class Sheet.Set
> * most private methods in Sheet and Sheet.Set should be protected instead
> * PropertySupport.Reflection class should have getters for read and write
> methods
> I wonder, what is the rationale for so strict and static API design? I would
> assume the performance gains from these limitations are meager. Opening these
> classes for sub-classing and modifications would result in much more flexible
> system with much less code duplication.
--
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] [Commented] (NETBEANS-4237) Package as DMG Image fails with "Bundler DMG Installer skipped because of a configuration problem"
[
https://issues.apache.org/jira/browse/NETBEANS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091519#comment-17091519
]
David Gradwell commented on NETBEANS-4237:
--
Also noted the following Terminal command line output:
_WARNING: An illegal reflective access operation has occurred_
_WARNING: Illegal reflective access by org.netbeans.core.output2.FileMapStorage
(jar:file:/Volumes/DJLGUSBDRIVE1/Apache/NetBeans/Release12beta3/netbeans/platform/modules/org-netbeans-core-output2.jar!/)
to method java.nio.DirectByteBuffer.cleaner()_
_WARNING: Please consider reporting this to the maintainers of
org.netbeans.core.output2.FileMapStorage_
_WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations_
_WARNING: All illegal access operations will be denied in a future release_
> Package as DMG Image fails with "Bundler DMG Installer skipped because of a
> configuration problem"
> --
>
> Key: NETBEANS-4237
> URL: https://issues.apache.org/jira/browse/NETBEANS-4237
> Project: NetBeans
> Issue Type: Bug
> Components: core
>Affects Versions: 12.1
> Environment: Mac OSX Catalina version 10.15.4
>Reporter: David Gradwell
>Priority: Major
>
> *Version*
> Actually running on version 12 beta 3 but that's not in the above list.
> *Steps to reproduce:*
> 1. Install fresh copy of 11.3 (also tested with 11.1 with same results)
> 2 Create new Project "Java with Ant", "Java Application".
> 3. Create a single Java file such as:
> package testmacdmgwithant;
> public class TestMacDMGwithAnt {
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args) \{ int a=1; }
> }
>
> 4. Go clean and build and debug to prove it works OK.
> 5. Run the .jar in the dist folder to prove it works OK.
> 6. Go right click on the project and select "Package as DMG Image"
>
> End of output is:
>
> _Launching task from
> /Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/lib/ant-javafx.jar_
> _Warning: Nashorn engine is planned to be removed from a future JDK release_
> _Note: To create native bundles the task may require external
> tools. See JavaFX 2.2+ documentation for details._
> _Launching in native packager mode..._
> _No base JDK. Package will use system JRE._
> _No base JDK. Package will use system JRE._
> _Bundler DMG Installer skipped because of a configuration problem: Cannot
> determine which JRE/JDK exists in the specified runtime directory._
> _Advice to fix: Point the runtime directory to one of the JDK/JRE root, the
> Contents/Home directory of that root, or the Contents/Home/jre directory of
> the JDK._
>
> Then tried to change the platform at project
> Properties/Run/RuntimePlatform/ManagePlatforms but selecting a new platform
> had no effect.
--
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
[netbeans] branch master updated: Adding end-of-line switcher.
This is an automated email from the ASF dual-hosted git repository.
skygo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
The following commit(s) were added to refs/heads/master by this push:
new fce86d5 Adding end-of-line switcher.
new 81339c2 Merge pull request #2049 from jlahoda/eol-switcher
fce86d5 is described below
commit fce86d52bcedc5b3579fc8da1ccf13237ad67619
Author: Jan Lahoda
AuthorDate: Fri Mar 27 07:16:07 2020 +0100
Adding end-of-line switcher.
---
.../modules/editor/impl/crlf/CRLFStatus.java | 226 +
1 file changed, 226 insertions(+)
diff --git
a/ide/editor/src/org/netbeans/modules/editor/impl/crlf/CRLFStatus.java
b/ide/editor/src/org/netbeans/modules/editor/impl/crlf/CRLFStatus.java
new file mode 100644
index 000..7f5f720
--- /dev/null
+++ b/ide/editor/src/org/netbeans/modules/editor/impl/crlf/CRLFStatus.java
@@ -0,0 +1,226 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.netbeans.modules.editor.impl.crlf;
+
+import java.awt.AWTEvent;
+import java.awt.BorderLayout;
+import java.awt.Color;
+import java.awt.Component;
+import java.awt.Dimension;
+import java.awt.FontMetrics;
+import java.awt.Insets;
+import java.awt.Point;
+import java.awt.Toolkit;
+import java.awt.event.AWTEventListener;
+import java.awt.event.MouseAdapter;
+import java.awt.event.MouseEvent;
+import java.beans.PropertyChangeEvent;
+import java.beans.PropertyChangeListener;
+import java.lang.reflect.Method;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.logging.Level;
+import java.util.logging.Logger;
+import javax.swing.BorderFactory;
+import javax.swing.DefaultListCellRenderer;
+import javax.swing.DefaultListModel;
+import javax.swing.JLabel;
+import javax.swing.JList;
+import javax.swing.JPanel;
+import javax.swing.JSeparator;
+import javax.swing.Popup;
+import javax.swing.PopupFactory;
+import javax.swing.SwingConstants;
+import javax.swing.border.Border;
+import javax.swing.border.LineBorder;
+import javax.swing.event.ListSelectionEvent;
+import javax.swing.event.ListSelectionListener;
+import javax.swing.text.Document;
+import javax.swing.text.JTextComponent;
+import org.netbeans.api.editor.EditorRegistry;
+import org.netbeans.editor.BaseDocument;
+import org.netbeans.modules.editor.NbEditorUtilities;
+import org.openide.awt.StatusLineElementProvider;
+import org.openide.cookies.EditorCookie;
+import org.openide.loaders.DataObject;
+import org.openide.text.CloneableEditorSupport;
+import org.openide.util.NbBundle;
+import org.openide.util.lookup.ServiceProvider;
+
+/**
+ *
+ * @author lahvac
+ */
+@NbBundle.Messages({
+"LBL_CR=Mac OS 9 (CR)",
+"LBL_CRLF=Windows (CRLF)",
+"LBL_LF=Unix (LF)",
+"LBL_Unknown=Unknown"
+})
+public class CRLFStatus {
+
+private static final Insets NULL_INSETS = new Insets(0, 0, 0, 0);
+private static final JLabel GLOBAL_CRLF = new JLabel("");
+private static final Map LINE_ENDINGS_DN = new
HashMap();
+private static final String UNKNOWN = Bundle.LBL_Unknown();
+
+static {
+LINE_ENDINGS_DN.put(BaseDocument.LS_CR, Bundle.LBL_CR());
+LINE_ENDINGS_DN.put(BaseDocument.LS_CRLF, Bundle.LBL_CRLF());
+LINE_ENDINGS_DN.put(BaseDocument.LS_LF, Bundle.LBL_LF());
+
+EditorRegistry.addPropertyChangeListener(new PropertyChangeListener() {
+@Override public void propertyChange(PropertyChangeEvent evt) {
+updateCRLFComponent();
+}
+});
+
+GLOBAL_CRLF.addMouseListener(new MouseAdapter() {
+@Override public void mouseClicked(MouseEvent e) {
+final JTextComponent comp = EditorRegistry.focusedComponent();
+
+if (comp == null) {
+Toolkit.getDefaultToolkit().beep();
+return;
+}
+
+final JList l = new JList();
+DefaultListModel model = new DefaultListModel();
+
+for (String k : LINE_ENDINGS_DN.keySet()) {
+model.addElement(k);
+}
+
+
[jira] [Commented] (NETBEANS-4237) Package as DMG Image fails with "Bundler DMG Installer skipped because of a configuration problem"
[
https://issues.apache.org/jira/browse/NETBEANS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091498#comment-17091498
]
Geertjan Wielenga commented on NETBEANS-4237:
-
Makes sense. JDK 14 does not include JavaFX.
> Package as DMG Image fails with "Bundler DMG Installer skipped because of a
> configuration problem"
> --
>
> Key: NETBEANS-4237
> URL: https://issues.apache.org/jira/browse/NETBEANS-4237
> Project: NetBeans
> Issue Type: Bug
> Components: core
>Affects Versions: 12.1
> Environment: Mac OSX Catalina version 10.15.4
>Reporter: David Gradwell
>Priority: Major
>
> *Version*
> Actually running on version 12 beta 3 but that's not in the above list.
> *Steps to reproduce:*
> 1. Install fresh copy of 11.3 (also tested with 11.1 with same results)
> 2 Create new Project "Java with Ant", "Java Application".
> 3. Create a single Java file such as:
> package testmacdmgwithant;
> public class TestMacDMGwithAnt {
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args) \{ int a=1; }
> }
>
> 4. Go clean and build and debug to prove it works OK.
> 5. Run the .jar in the dist folder to prove it works OK.
> 6. Go right click on the project and select "Package as DMG Image"
>
> End of output is:
>
> _Launching task from
> /Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/lib/ant-javafx.jar_
> _Warning: Nashorn engine is planned to be removed from a future JDK release_
> _Note: To create native bundles the task may require external
> tools. See JavaFX 2.2+ documentation for details._
> _Launching in native packager mode..._
> _No base JDK. Package will use system JRE._
> _No base JDK. Package will use system JRE._
> _Bundler DMG Installer skipped because of a configuration problem: Cannot
> determine which JRE/JDK exists in the specified runtime directory._
> _Advice to fix: Point the runtime directory to one of the JDK/JRE root, the
> Contents/Home directory of that root, or the Contents/Home/jre directory of
> the JDK._
>
> Then tried to change the platform at project
> Properties/Run/RuntimePlatform/ManagePlatforms but selecting a new platform
> had no effect.
--
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] [Commented] (NETBEANS-4237) Package as DMG Image fails with "Bundler DMG Installer skipped because of a configuration problem"
[
https://issues.apache.org/jira/browse/NETBEANS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091494#comment-17091494
]
David Gradwell commented on NETBEANS-4237:
--
When I reset JAVA_HOME (export
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-14.jdk/Contents/Home) in my
.bash_profile I get
_Created dir:
/Users/davidjlgradwell/NetBeansDev/TestMacOSXPackagingWithAnt/dist_
_Warning: Nashorn engine is planned to be removed from a future JDK release_
_Warning: Nashorn engine is planned to be removed from a future JDK release_
_/Users/davidjlgradwell/NetBeansDev/TestMacOSXPackagingWithAnt/nbproject/build-native.xml:519:
typedef class {color:#FF}com.sun.javafx.tools.ant.FXJar{color} cannot be
found_
_using the classloader AntClassLoader[]_
_BUILD FAILED (total time: 1 second)_
> Package as DMG Image fails with "Bundler DMG Installer skipped because of a
> configuration problem"
> --
>
> Key: NETBEANS-4237
> URL: https://issues.apache.org/jira/browse/NETBEANS-4237
> Project: NetBeans
> Issue Type: Bug
> Components: core
>Affects Versions: 12.1
> Environment: Mac OSX Catalina version 10.15.4
>Reporter: David Gradwell
>Priority: Major
>
> *Version*
> Actually running on version 12 beta 3 but that's not in the above list.
> *Steps to reproduce:*
> 1. Install fresh copy of 11.3 (also tested with 11.1 with same results)
> 2 Create new Project "Java with Ant", "Java Application".
> 3. Create a single Java file such as:
> package testmacdmgwithant;
> public class TestMacDMGwithAnt {
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args) \{ int a=1; }
> }
>
> 4. Go clean and build and debug to prove it works OK.
> 5. Run the .jar in the dist folder to prove it works OK.
> 6. Go right click on the project and select "Package as DMG Image"
>
> End of output is:
>
> _Launching task from
> /Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/lib/ant-javafx.jar_
> _Warning: Nashorn engine is planned to be removed from a future JDK release_
> _Note: To create native bundles the task may require external
> tools. See JavaFX 2.2+ documentation for details._
> _Launching in native packager mode..._
> _No base JDK. Package will use system JRE._
> _No base JDK. Package will use system JRE._
> _Bundler DMG Installer skipped because of a configuration problem: Cannot
> determine which JRE/JDK exists in the specified runtime directory._
> _Advice to fix: Point the runtime directory to one of the JDK/JRE root, the
> Contents/Home directory of that root, or the Contents/Home/jre directory of
> the JDK._
>
> Then tried to change the platform at project
> Properties/Run/RuntimePlatform/ManagePlatforms but selecting a new platform
> had no effect.
--
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] [Commented] (NETBEANS-4237) Package as DMG Image fails with "Bundler DMG Installer skipped because of a configuration problem"
[
https://issues.apache.org/jira/browse/NETBEANS-4237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091484#comment-17091484
]
David Gradwell commented on NETBEANS-4237:
--
Changed project Properties/Sorces/Source/Binary format to JDK 14. Changed
Properties/Libraries/Java Platform to JDK 14. Noted that netbeans.conf has
netbeans_jdkhome commented out. (Unchabged since install).
Note clear why it is launching _ant-javafx.jar_ from Java 1.8 (which is the
machine default but not that specified anywhere in NetBeans.
_Launching task from
/Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/lib/ant-javafx.jar_
Same results.
> Package as DMG Image fails with "Bundler DMG Installer skipped because of a
> configuration problem"
> --
>
> Key: NETBEANS-4237
> URL: https://issues.apache.org/jira/browse/NETBEANS-4237
> Project: NetBeans
> Issue Type: Bug
> Components: core
>Affects Versions: 12.1
> Environment: Mac OSX Catalina version 10.15.4
>Reporter: David Gradwell
>Priority: Major
>
> *Version*
> Actually running on version 12 beta 3 but that's not in the above list.
> *Steps to reproduce:*
> 1. Install fresh copy of 11.3 (also tested with 11.1 with same results)
> 2 Create new Project "Java with Ant", "Java Application".
> 3. Create a single Java file such as:
> package testmacdmgwithant;
> public class TestMacDMGwithAnt {
> /**
> * @param args the command line arguments
> */
> public static void main(String[] args) \{ int a=1; }
> }
>
> 4. Go clean and build and debug to prove it works OK.
> 5. Run the .jar in the dist folder to prove it works OK.
> 6. Go right click on the project and select "Package as DMG Image"
>
> End of output is:
>
> _Launching task from
> /Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/lib/ant-javafx.jar_
> _Warning: Nashorn engine is planned to be removed from a future JDK release_
> _Note: To create native bundles the task may require external
> tools. See JavaFX 2.2+ documentation for details._
> _Launching in native packager mode..._
> _No base JDK. Package will use system JRE._
> _No base JDK. Package will use system JRE._
> _Bundler DMG Installer skipped because of a configuration problem: Cannot
> determine which JRE/JDK exists in the specified runtime directory._
> _Advice to fix: Point the runtime directory to one of the JDK/JRE root, the
> Contents/Home directory of that root, or the Contents/Home/jre directory of
> the JDK._
>
> Then tried to change the platform at project
> Properties/Run/RuntimePlatform/ManagePlatforms but selecting a new platform
> had no effect.
--
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] [Assigned] (NETBEANS-4159) Internal hint engine for EE feature resolves class version to JDK6
[
https://issues.apache.org/jira/browse/NETBEANS-4159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Graf reassigned NETBEANS-4159:
---
Assignee: Benjamin Graf
> Internal hint engine for EE feature resolves class version to JDK6
> --
>
> Key: NETBEANS-4159
> URL: https://issues.apache.org/jira/browse/NETBEANS-4159
> Project: NetBeans
> Issue Type: Bug
> Components: editor - Hints Annotations
>Affects Versions: 12.0
> Environment: Product Version: Apache NetBeans IDE DEV (Build
> dev-1718236e226adfd9aa5a48d9be74b2a95a63b050)
> Java: 14; OpenJDK 64-Bit Server VM 14+36
> Runtime: OpenJDK Runtime Environment 14+36
> System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb)
>Reporter: Benjamin Graf
>Assignee: Benjamin Graf
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Simple test class using JDK14 feature (e.g. record) always throws Exception
> while resolving hints.
> {noformat}
> javax.lang.model.element.UnknownElementException: Unknown element:
> "javaapplication1.JavaApplication1.Point"
> at
> java.compiler@14/javax.lang.model.util.AbstractElementVisitor6.visitUnknown(AbstractElementVisitor6.java:126)
> at
> java.compiler@14/javax.lang.model.util.ElementKindVisitor6.visitTypeAsRecord(ElementKindVisitor6.java:240)
> at
> java.compiler@14/javax.lang.model.util.ElementKindVisitor6.visitType(ElementKindVisitor6.java:160)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1522)
> at
> org.netbeans.modules.websvc.editor.hints.common.RulesEngine.visitTypeAsClass(RulesEngine.java:61)
> at
> org.netbeans.modules.websvc.editor.hints.common.RulesEngine.visitTypeAsClass(RulesEngine.java:37)
> at
> java.compiler@14/javax.lang.model.util.ElementKindVisitor6.visitType(ElementKindVisitor6.java:151)
> at
> jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1522)
> at
> org.netbeans.modules.websvc.editor.hints.WebServicesHintsProvider.run(WebServicesHintsProvider.java:112)
> at
> org.netbeans.modules.websvc.editor.hints.WebServicesHintsProvider$ProblemFinderCompInfo.run(WebServicesHintsProvider.java:187)
> [catch] at
> org.netbeans.modules.java.source.JavaSourceAccessor$CancelableTaskWrapper.run(JavaSourceAccessor.java:273)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor.callParserResultTask(TaskProcessor.java:561)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(TaskProcessor.java:786)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:279)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.execute(TaskProcessor.java:702)
> at
> org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:663)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418)
> at
> org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45)
> at org.openide.util.lookup.Lookups.executeWith(Lookups.java:278)
> at
> org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2033)
> {noformat}
> Reproduce:
> 1. Create Java Application (tested with and and maven based project)
> 2. Write some simple JDK14 record class
> 3. Activate EE feature if not activated yet
--
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] [Created] (NETBEANS-4237) Package as DMG Image fails with "Bundler DMG Installer skipped because of a configuration problem"
David Gradwell created NETBEANS-4237:
Summary: Package as DMG Image fails with "Bundler DMG Installer
skipped because of a configuration problem"
Key: NETBEANS-4237
URL: https://issues.apache.org/jira/browse/NETBEANS-4237
Project: NetBeans
Issue Type: Bug
Components: core
Affects Versions: 12.1
Environment: Mac OSX Catalina version 10.15.4
Reporter: David Gradwell
*Version*
Actually running on version 12 beta 3 but that's not in the above list.
*Steps to reproduce:*
1. Install fresh copy of 11.3 (also tested with 11.1 with same results)
2 Create new Project "Java with Ant", "Java Application".
3. Create a single Java file such as:
package testmacdmgwithant;
public class TestMacDMGwithAnt {
/**
* @param args the command line arguments
*/
public static void main(String[] args) \{ int a=1; }
}
4. Go clean and build and debug to prove it works OK.
5. Run the .jar in the dist folder to prove it works OK.
6. Go right click on the project and select "Package as DMG Image"
End of output is:
_Launching task from
/Library/Java/JavaVirtualMachines/jdk1.8.0_221.jdk/Contents/Home/lib/ant-javafx.jar_
_Warning: Nashorn engine is planned to be removed from a future JDK release_
_Note: To create native bundles the task may require external
tools. See JavaFX 2.2+ documentation for details._
_Launching in native packager mode..._
_No base JDK. Package will use system JRE._
_No base JDK. Package will use system JRE._
_Bundler DMG Installer skipped because of a configuration problem: Cannot
determine which JRE/JDK exists in the specified runtime directory._
_Advice to fix: Point the runtime directory to one of the JDK/JRE root, the
Contents/Home directory of that root, or the Contents/Home/jre directory of the
JDK._
Then tried to change the platform at project
Properties/Run/RuntimePlatform/ManagePlatforms but selecting a new platform had
no effect.
--
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
[netbeans] branch master updated: If cancel happens while Analyzer is running, AssertionError is thrown. Rather ignore all exception happening while the parser is cancelled.
This is an automated email from the ASF dual-hosted git repository.
skygo pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans.git
The following commit(s) were added to refs/heads/master by this push:
new 05e9abe If cancel happens while Analyzer is running, AssertionError
is thrown. Rather ignore all exception happening while the parser is cancelled.
new f445170 Merge pull request #2095 from
jlahoda/ignore-cancel-in-analyzer
05e9abe is described below
commit 05e9abe79fdc032d7d678c578fdd3a2447126209
Author: Jan Lahoda
AuthorDate: Tue Apr 21 07:38:24 2020 +0200
If cancel happens while Analyzer is running, AssertionError is thrown.
Rather ignore all exception happening while the parser is cancelled.
---
.../org/netbeans/modules/java/source/parsing/JavacParser.java | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git
a/java/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
b/java/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
index 7231327..ca0f9bd 100644
---
a/java/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
+++
b/java/java.source.base/src/org/netbeans/modules/java/source/parsing/JavacParser.java
@@ -709,9 +709,14 @@ public class JavacParser extends Parser {
} catch (Abort abort) {
parserError = currentPhase;
} catch (RuntimeException | Error ex) {
-parserError = currentPhase;
-dumpSource(currentInfo, ex);
-throw ex;
+if (cancellable && parserCanceled.get()) {
+currentPhase = Phase.MODIFIED;
+invalidate(false);
+} else {
+parserError = currentPhase;
+dumpSource(currentInfo, ex);
+throw ex;
+}
} finally {
currentInfo.setPhase(currentPhase);
currentInfo.parserCrashed = parserError;
-
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
[netbeans] branch master updated (1a8548d -> 2eb871f)
This is an automated email from the ASF dual-hosted git repository. skygo pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans.git. from 1a8548d Merge pull request #2076 from eirikbakke/NETBEANS-346 add 439859c [TRAVIS] Enable cache add 2eb871f Merge pull request #2085 from apache/travis_cache No new revisions were added by this update. Summary of changes: .travis.yml | 5 + 1 file changed, 5 insertions(+) - 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
[netbeans] branch master updated (2eb871f -> b7cde74)
This is an automated email from the ASF dual-hosted git repository. skygo pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans.git. from 2eb871f Merge pull request #2085 from apache/travis_cache add 41f57c5 [Travis] Retry java module add b7cde74 Merge pull request #2101 from apache/hectorespert-patch-1 No new revisions were added by this update. Summary of changes: .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - 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-4209) Truffle debugger: some variable values are displayed as DynamicObjectBasic
[
https://issues.apache.org/jira/browse/NETBEANS-4209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Entlicher updated NETBEANS-4209:
---
Fix Version/s: 12.0
> Truffle debugger: some variable values are displayed as DynamicObjectBasic
> --
>
> Key: NETBEANS-4209
> URL: https://issues.apache.org/jira/browse/NETBEANS-4209
> Project: NetBeans
> Issue Type: Bug
> Components: debugger - Java
>Affects Versions: 11.2
>Reporter: Martin Entlicher
>Assignee: Martin Entlicher
>Priority: Major
> Fix For: 12.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> With the new GraalVM 20.1.0 some variable values are displayed as e.g.
> {{com.oracle.truffle.object.DynamicObjectBasic@1e3f86d5}} instead of the
> proper guest language representation.
--
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] [Created] (NETBEANS-4236) A java.lang.AssertionError exception has occurred running a gradle build.
Ian Martin James Berry created NETBEANS-4236: Summary: A java.lang.AssertionError exception has occurred running a gradle build. Key: NETBEANS-4236 URL: https://issues.apache.org/jira/browse/NETBEANS-4236 Project: NetBeans Issue Type: Bug Components: java - Compiler Affects Versions: 11.3 Environment: Windows 10 64 bit. Acer Aspire V5-552P Laptop with AMD A10 64bit processor. Reporter: Ian Martin James Berry Attachments: IDE Log.txt, UI Log.txt, error.txt, messages.log A java.lang.AssertionError exception has occurred. What I did Following tutorial here; https://spring.io/guides/gs/spring-boot/ I downloaded the source from here; https://github.com/spring-guides/gs-spring-boot/archive/master.zip The error occurred after I added a simple full-stack integration test and tried to build the project again to compile it. -- 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] [Created] (NETBEANS-4235) Formatting Issue in Records
Arunava Sinha created NETBEANS-4235:
---
Summary: Formatting Issue in Records
Key: NETBEANS-4235
URL: https://issues.apache.org/jira/browse/NETBEANS-4235
Project: NetBeans
Issue Type: Bug
Components: java - Editor
Affects Versions: 11.3
Reporter: Arunava Sinha
Assignee: Arunava Sinha
Formatting of below code snippet is not proper in Jdk-14/jdk-15
public record Rec1{}
expected output
public record Rec1{
}
actual output
public record Rec1{
}
--
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
