[jira] [Commented] (NETBEANS-6179) Open Project dialog can take over 30 seconds to appear on Windows.

2021-11-08 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-6179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440456#comment-17440456
 ] 

Scott Palmer commented on NETBEANS-6179:


Yes, this also happens with Windows LaF and when running with JDK 16.

> Open Project dialog can take over 30 seconds to appear on Windows.
> --
>
> Key: NETBEANS-6179
> URL: https://issues.apache.org/jira/browse/NETBEANS-6179
> Project: NetBeans
>  Issue Type: Bug
>  Components: ide - Performance
> Environment: Wndows10 Pro
> Java 17.0.1 (Zulu + JavaFX)
> NetBeans 12.6-rc2 (and earlier)
>Reporter: Scott Palmer
>Priority: Major
>  Labels: performance
> Attachments: NetBeans126_OpenProject.nps, NetBeans126_OpenProject2.nps
>
>
> On Windows systems with disconnected mapped network drives, the "Open 
> Project" dialog can take over 30 seconds to appear.  The "Open File" dialog 
> does not suffer from this issue.
> While attempts to actually access the unavailable network drives can 
> logically lead to timeouts, since the open Project dialog will initially be 
> browsing in folder unrelated to the disconnected drive letters, there is no 
> reason that they should be holding up the initialization of the dialog.
> VisualVM snapshot data collected while triggering and waiting for the Open 
> Project dialog is attached.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
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-6179) Open Project dialog can take over 30 seconds to appear on Windows.

2021-11-06 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-6179:
--

 Summary: Open Project dialog can take over 30 seconds to appear on 
Windows.
 Key: NETBEANS-6179
 URL: https://issues.apache.org/jira/browse/NETBEANS-6179
 Project: NetBeans
  Issue Type: Bug
  Components: ide - Performance
 Environment: Wndows10 Pro
Java 17.0.1 (Zulu + JavaFX)
NetBeans 12.6-rc2 (and earlier)


Reporter: Scott Palmer
 Attachments: NetBeans126_OpenProject.nps, NetBeans126_OpenProject2.nps

On Windows systems with disconnected mapped network drives, the "Open Project" 
dialog can take over 30 seconds to appear.  The "Open File" dialog does not 
suffer from this issue.
While attempts to actually access the unavailable network drives can logically 
lead to timeouts, since the open Project dialog will initially be browsing in 
folder unrelated to the disconnected drive letters, there is no reason that 
they should be holding up the initialization of the dialog.

VisualVM snapshot data collected while triggering and waiting for the Open 
Project dialog is attached.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

-
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-5783) NPE opening Gradle project

2021-06-15 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-5783:
--

 Summary: NPE opening Gradle project
 Key: NETBEANS-5783
 URL: https://issues.apache.org/jira/browse/NETBEANS-5783
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Gradle
Affects Versions: 12.4
 Environment: NetBeans 12.4
OpenJDK 16
macOS 11.4
Reporter: Scott Palmer
Assignee: Laszlo Kishalmi


I have an existing Gradle project that builds fine from the command line, but 
causes a NPE related to the project name when I try to load it into NetBeans:

java.lang.NullPointerException: Cannot invoke "String.equals(Object)" because 
the return value of 
"org.netbeans.api.project.ProjectInformation.getDisplayName()" is null
at 
org.netbeans.modules.project.ui.actions.SetMainProject.checkProjectNames(SetMainProject.java:277)
at 
org.netbeans.modules.project.ui.actions.SetMainProject.access$200(SetMainProject.java:66)
at 
org.netbeans.modules.project.ui.actions.SetMainProject$5.run(SetMainProject.java:303)
at 
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:316)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)


There are spaces in the path to the project but not the project folder itself.



--
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-5768) Gradle projects with settings.gradle but not build.gradle are not recognized

2021-06-09 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-5768:
---
Description: 
Running "gradle init" to initialize a new Java application project will make a 
project structure with a few sub projects (application and libraries), but no 
build.gradle file in the root.  It just has the settings.gradle file that 
points to the sub-projects.
NetBeans project open dialog does not recognize the root folder as a project.
A simple work around is to make an empty build.gradle file in the root folder 
of the project, but NetBeans should be able to handle this valid project 
structure, particularly since it is the "default" structure coming from "gradle 
init"



  was:
Running "gradle init" to initialize a new Java application project will make a 
project structure with a few sub projects (application and libraries), but no 
build.gradle file in the root.  It just has the settings.gradle file that 
points to the sub-projects.
NetBeans project open dialog does not recognize the root folder as a project.
A simple work around is to make an empty build.gradle file in the root folder 
of the project, but NetBeans should be able to handle this valid project 
structure, particularly singe it is the "default" structure coming from "gradle 
init"




> Gradle projects with settings.gradle but not build.gradle are not recognized
> 
>
> Key: NETBEANS-5768
> URL: https://issues.apache.org/jira/browse/NETBEANS-5768
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Gradle
>Affects Versions: 12.4
> Environment: Gradle 7.0.2
> NetBeans 12.4
> OpenJDK 16
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Running "gradle init" to initialize a new Java application project will make 
> a project structure with a few sub projects (application and libraries), but 
> no build.gradle file in the root.  It just has the settings.gradle file that 
> points to the sub-projects.
> NetBeans project open dialog does not recognize the root folder as a project.
> A simple work around is to make an empty build.gradle file in the root folder 
> of the project, but NetBeans should be able to handle this valid project 
> structure, particularly since it is the "default" structure coming from 
> "gradle init"



--
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-5768) Gradle projects with settings.gradle but not build.gradle are not recognized

2021-06-09 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-5768:
--

 Summary: Gradle projects with settings.gradle but not build.gradle 
are not recognized
 Key: NETBEANS-5768
 URL: https://issues.apache.org/jira/browse/NETBEANS-5768
 Project: NetBeans
  Issue Type: Improvement
  Components: projects - Gradle
Affects Versions: 12.4
 Environment: Gradle 7.0.2
NetBeans 12.4
OpenJDK 16

Reporter: Scott Palmer
Assignee: Laszlo Kishalmi


Running "gradle init" to initialize a new Java application project will make a 
project structure with a few sub projects (application and libraries), but no 
build.gradle file in the root.  It just has the settings.gradle file that 
points to the sub-projects.
NetBeans project open dialog does not recognize the root folder as a project.
A simple work around is to make an empty build.gradle file in the root folder 
of the project, but NetBeans should be able to handle this valid project 
structure, particularly singe it is the "default" structure coming from "gradle 
init"





--
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-5522) NetBeans 12.3 cannot open Gradle projects that use Gradle 7.0-rc-1

2021-03-30 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-5522:
---
Description: 
Projects configured to use Gradle 7.0-rc-1 cause NetBeans 12.3 to complain when 
being opened.
The error reported is:
"Could not get unknown property 'compileConfigurationName' for source set 
'main' of type org.gradle.api.internal.tasks.DefaultSourceSet."

To reproduce:
- ensure NetBeans Gradle settings will use the gradle wrapper if present
- create a new Java Library project from the command line with 'gradle init'
- run: gradle wrapper --gradle-version=7.0-rc-1
- attempt to open the project in NetBeans
- allow NB to run the initial configuration build


  was:
Projects configured to use Gradle 7.0-rc-1 cause NetBans 12.3 to complain when 
being opened.
The error reported is:
"Could not get unknown property 'compileConfigurationName' for source set 
'main' of type org.gradle.api.internal.tasks.DefaultSourceSet."

To reproduce:
- ensure NetBeans Gradle settings will use the gradle wrapper if present
- create a new Java Library project with 'gradle init'
- run: gradle wrapper --gradle-version=7.0-rc-1
- attempt to open the project in NetBeans
- allow NB to run the initial configuration build



> NetBeans 12.3 cannot open Gradle projects that use Gradle 7.0-rc-1
> --
>
> Key: NETBEANS-5522
> URL: https://issues.apache.org/jira/browse/NETBEANS-5522
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 12.3
> Environment: Windows 10
> Java 15
> Netbeans 12.3
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Projects configured to use Gradle 7.0-rc-1 cause NetBeans 12.3 to complain 
> when being opened.
> The error reported is:
> "Could not get unknown property 'compileConfigurationName' for source set 
> 'main' of type org.gradle.api.internal.tasks.DefaultSourceSet."
> To reproduce:
> - ensure NetBeans Gradle settings will use the gradle wrapper if present
> - create a new Java Library project from the command line with 'gradle init'
> - run: gradle wrapper --gradle-version=7.0-rc-1
> - attempt to open the project in NetBeans
> - allow NB to run the initial configuration build



--
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-5098) SessionBean - EJB Container initialization error

2021-03-30 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer reassigned NETBEANS-5098:
--

Assignee: Laszlo Kishalmi  (was: Laszlo Hordos)

> SessionBean - EJB Container initialization error
> 
>
> Key: NETBEANS-5098
> URL: https://issues.apache.org/jira/browse/NETBEANS-5098
> Project: NetBeans
>  Issue Type: Bug
>  Components: javaee - EJB
>Affects Versions: 12.2, 12.3
> Environment: Netbeans 12.3, glassfish-4.1.2, jdk-15.0.1
>Reporter: S. M.
>Assignee: Laszlo Kishalmi
>Priority: Blocker
>
> Reopened because: It worked with new NB 12.3 for a week or so - now the 
> Exception popped up again and is lasting now. There where no changes made 
> from my side.
> By the way: NETBEANS-5099 popped up at the same time.
> The exactly same code works fine when it is compiled and deployed outside 
> Netbeans or with an older Netbeans version. So I feel it is a Netbeans Issue.
> How to reproduce: Make a new Java Ant/Java Enterprise/EJB Module and add an 
> 'empty' Session-EJB to the project: 
> (The critical point seems to be the LocalBean annotation. When the local 
> interface is implemented by a concrete class it works.)
> {code}
> package test;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> @Stateless
> @LocalBean
>  public class NewSessionBean {
>  }
> {code}
> Deploy the module within Netbeans to Glassfish.
> The exactly same code works fine when it is deployed outside Netbeans or with 
> an older Netbeans version. So I feel it is a Netbeans Issue.
> At deployment on Glassfish 5 the following Exeption occurs:
> {code}
> java.lang.RuntimeException: EJB Container initialization error
>   at 
> org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
>   at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
>   at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
>   at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
>   at 
> org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
>   at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
>   at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
>   at 
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
>   at 
> com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
>   at 
> com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
>   at 
> org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
>   at 
> com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
>   at 
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
>   at 
> org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
>   at 
> org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
>   at 
> org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
>   at 
> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>   at 
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
>   at 
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
> 

[jira] [Assigned] (NETBEANS-5098) SessionBean - EJB Container initialization error

2021-03-30 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer reassigned NETBEANS-5098:
--

Assignee: (was: Laszlo Kishalmi)

> SessionBean - EJB Container initialization error
> 
>
> Key: NETBEANS-5098
> URL: https://issues.apache.org/jira/browse/NETBEANS-5098
> Project: NetBeans
>  Issue Type: Bug
>  Components: javaee - EJB
>Affects Versions: 12.2, 12.3
> Environment: Netbeans 12.3, glassfish-4.1.2, jdk-15.0.1
>Reporter: S. M.
>Priority: Blocker
>
> Reopened because: It worked with new NB 12.3 for a week or so - now the 
> Exception popped up again and is lasting now. There where no changes made 
> from my side.
> By the way: NETBEANS-5099 popped up at the same time.
> The exactly same code works fine when it is compiled and deployed outside 
> Netbeans or with an older Netbeans version. So I feel it is a Netbeans Issue.
> How to reproduce: Make a new Java Ant/Java Enterprise/EJB Module and add an 
> 'empty' Session-EJB to the project: 
> (The critical point seems to be the LocalBean annotation. When the local 
> interface is implemented by a concrete class it works.)
> {code}
> package test;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> @Stateless
> @LocalBean
>  public class NewSessionBean {
>  }
> {code}
> Deploy the module within Netbeans to Glassfish.
> The exactly same code works fine when it is deployed outside Netbeans or with 
> an older Netbeans version. So I feel it is a Netbeans Issue.
> At deployment on Glassfish 5 the following Exeption occurs:
> {code}
> java.lang.RuntimeException: EJB Container initialization error
>   at 
> org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
>   at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
>   at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
>   at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
>   at 
> org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
>   at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
>   at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
>   at 
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
>   at 
> com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
>   at 
> com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
>   at 
> org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
>   at 
> com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
>   at 
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
>   at 
> org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
>   at 
> org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
>   at 
> org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
>   at 
> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>   at 
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
>   at 
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
>   at 
> 

[jira] [Assigned] (NETBEANS-5098) SessionBean - EJB Container initialization error

2021-03-30 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-5098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer reassigned NETBEANS-5098:
--

Assignee: Laszlo Hordos

> SessionBean - EJB Container initialization error
> 
>
> Key: NETBEANS-5098
> URL: https://issues.apache.org/jira/browse/NETBEANS-5098
> Project: NetBeans
>  Issue Type: Bug
>  Components: javaee - EJB
>Affects Versions: 12.2, 12.3
> Environment: Netbeans 12.3, glassfish-4.1.2, jdk-15.0.1
>Reporter: S. M.
>Assignee: Laszlo Hordos
>Priority: Blocker
>
> Reopened because: It worked with new NB 12.3 for a week or so - now the 
> Exception popped up again and is lasting now. There where no changes made 
> from my side.
> By the way: NETBEANS-5099 popped up at the same time.
> The exactly same code works fine when it is compiled and deployed outside 
> Netbeans or with an older Netbeans version. So I feel it is a Netbeans Issue.
> How to reproduce: Make a new Java Ant/Java Enterprise/EJB Module and add an 
> 'empty' Session-EJB to the project: 
> (The critical point seems to be the LocalBean annotation. When the local 
> interface is implemented by a concrete class it works.)
> {code}
> package test;
> import javax.ejb.LocalBean;
> import javax.ejb.Stateless;
> @Stateless
> @LocalBean
>  public class NewSessionBean {
>  }
> {code}
> Deploy the module within Netbeans to Glassfish.
> The exactly same code works fine when it is deployed outside Netbeans or with 
> an older Netbeans version. So I feel it is a Netbeans Issue.
> At deployment on Glassfish 5 the following Exeption occurs:
> {code}
> java.lang.RuntimeException: EJB Container initialization error
>   at 
> org.glassfish.ejb.startup.EjbApplication.loadContainers(EjbApplication.java:234)
>   at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:291)
>   at org.glassfish.ejb.startup.EjbDeployer.load(EjbDeployer.java:99)
>   at org.glassfish.internal.data.ModuleInfo.load(ModuleInfo.java:206)
>   at 
> org.glassfish.internal.data.ApplicationInfo.load(ApplicationInfo.java:313)
>   at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:496)
>   at 
> com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:219)
>   at 
> org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:491)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:539)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2$1.run(CommandRunnerImpl.java:535)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$2.execute(CommandRunnerImpl.java:534)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:565)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$3.run(CommandRunnerImpl.java:557)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:360)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:556)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1464)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1300(CommandRunnerImpl.java:109)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1846)
>   at 
> com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1722)
>   at 
> com.sun.enterprise.v3.admin.AdminAdapter.doCommand(AdminAdapter.java:534)
>   at 
> com.sun.enterprise.v3.admin.AdminAdapter.onMissingResource(AdminAdapter.java:224)
>   at 
> org.glassfish.grizzly.http.server.StaticHttpHandlerBase.service(StaticHttpHandlerBase.java:189)
>   at 
> com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:459)
>   at 
> com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:167)
>   at 
> org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
>   at 
> org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
>   at 
> org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
>   at 
> org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>   at 
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:283)
>   at 
> org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
>   at 
> 

[jira] [Created] (NETBEANS-5522) NetBeans 12.3 cannot open Gradle projects that use Gradle 7.0-rc-1

2021-03-30 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-5522:
--

 Summary: NetBeans 12.3 cannot open Gradle projects that use Gradle 
7.0-rc-1
 Key: NETBEANS-5522
 URL: https://issues.apache.org/jira/browse/NETBEANS-5522
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Gradle
Affects Versions: 12.3
 Environment: Windows 10
Java 15
Netbeans 12.3

Reporter: Scott Palmer
Assignee: Laszlo Kishalmi


Projects configured to use Gradle 7.0-rc-1 cause NetBans 12.3 to complain when 
being opened.
The error reported is:
"Could not get unknown property 'compileConfigurationName' for source set 
'main' of type org.gradle.api.internal.tasks.DefaultSourceSet."

To reproduce:
- ensure NetBeans Gradle settings will use the gradle wrapper if present
- create a new Java Library project with 'gradle init'
- run: gradle wrapper --gradle-version=7.0-rc-1
- attempt to open the project in NetBeans
- allow NB to run the initial configuration build




--
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-5505) Pasting into a Java text block (multi-line string) fails to escape pasted backslashes

2021-03-26 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-5505:
--

 Summary: Pasting into a Java text block (multi-line string) fails 
to escape pasted backslashes
 Key: NETBEANS-5505
 URL: https://issues.apache.org/jira/browse/NETBEANS-5505
 Project: NetBeans
  Issue Type: Bug
  Components: java - Editor
Affects Versions: 12.3
 Environment: NetBeans 12.3
Windows 10
Java 15.0.2
Reporter: Scott Palmer


I had existing code with an empty text block
{code:java}
String text = """
""";
{code}
I copied some XML and pasted it into that block. Normally when pasting text 
into a Java String special characters are escaped e.g. quote characters are 
preceded with a backslash, backslashes are doubled up (e.g. a Windows path).

However when pasting into a text block single quotes don't need to be escaped, 
however backslashes were not escaped and they need to be.
See 
[https://docs.oracle.com/en/java/javase/15/text-blocks/index.html#translation-of-escape-sequences|https://docs.oracle.com/en/java/javase/15/text-blocks/index.html#translation-of-escape-sequences]
I ended up with this:
{code:java}
String text = """
C:\temp\MyProgram.log
""";
{code}
where the pasted lines with backslashes are marked as errors because the 
backslashes are not part of valid escape sequences, or they are valid escape 
sequences '\t' that do not correspond to the original text.



--
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-5177) Crash: cannot get exclusive access to uihandler.properties

2021-01-10 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17262266#comment-17262266
 ] 

Scott Palmer commented on NETBEANS-5177:


Interesting. As a temporary workaround, I wonder if users can try to keep 
things under control by manually triggering garbage collection (double click 
the memory histogram on the toolbar), before the problem presents.  Is there 
any finalizer/cleaner that might close the unreferenced Stream? 

> Crash: cannot get exclusive access to uihandler.properties
> --
>
> Key: NETBEANS-5177
> URL: https://issues.apache.org/jira/browse/NETBEANS-5177
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 12.2
>Reporter: Ulrich Mayring
>Assignee: Laszlo Kishalmi
>Priority: Blocker
> Attachments: messages.log, sc.png, screenshot2.png, thread_dump.rtf
>
>
> I experienced a number of total freezes after installing NB 12.2 (have been 
> using 12.0 before), but could not get an error message of any sort, since NB 
> was completely unresponsive to keystrokes or mouse. This changed today, I got 
> an error popup, which I attach. NB was again totally unresponsive, but I 
> could make a screenshot of the popup message.
> The black shadow around the error dialog actually is tens or hundreds of the 
> same popup windows behind the first one. They keep piling up at CPU speed 
> until the app runs out of memory or is killed. For a while I could close a 
> few of them, but they kept coming up faster than I could click.
> The file in question (see screenshot) looks normal to me. It has the correct 
> owner and permissions and its content is this:
> count=1000
>  MTTF=71985
>  uihandler.preferences.writable.check=1608633016127
> The crash happened directly after starting the IDE, while it was reading in 
> the last project I worked on. No user interaction was involved.
> Fedora 29 / KDE.



--
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-5177) Crash: cannot get exclusive access to uihandler.properties

2021-01-09 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261959#comment-17261959
 ] 

Scott Palmer edited comment on NETBEANS-5177 at 1/9/21, 10:32 PM:
--

I'm getting these errors after working for a while with Gradle-based projects.  
My guess would be that NetBeans (or the JRE) is leaking file handles.
I'm running NetBeans 12.2 on macOS Big Sur 11.1
{{
openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment Zulu15.28+51-CA (build 15.0.1+9)
OpenJDK 64-Bit Server VM Zulu15.28+51-CA (build 15.0.1+9, mixed mode, sharing)
}}

I never noticed anything like this prior to NB 12.2.


was (Author: swpalmer):
I'm getting these errors after working for a while with Gradle-based projects.  
My guess would be that NetBeans (or the JRE) is leaking file handles.
I'm running NetBeans 12.2 on macOS Big Sur 11.1
{{openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment Zulu15.28+51-CA (build 15.0.1+9)
OpenJDK 64-Bit Server VM Zulu15.28+51-CA (build 15.0.1+9, mixed mode, sharing)
}}

I never noticed anything like this prior to NB 12.2.

> Crash: cannot get exclusive access to uihandler.properties
> --
>
> Key: NETBEANS-5177
> URL: https://issues.apache.org/jira/browse/NETBEANS-5177
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.2
>Reporter: Ulrich Mayring
>Priority: Blocker
> Attachments: messages.log, sc.png, screenshot2.png, thread_dump.rtf
>
>
> I experienced a number of total freezes after installing NB 12.2 (have been 
> using 12.0 before), but could not get an error message of any sort, since NB 
> was completely unresponsive to keystrokes or mouse. This changed today, I got 
> an error popup, which I attach. NB was again totally unresponsive, but I 
> could make a screenshot of the popup message.
> The black shadow around the error dialog actually is tens or hundreds of the 
> same popup windows behind the first one. They keep piling up at CPU speed 
> until the app runs out of memory or is killed. For a while I could close a 
> few of them, but they kept coming up faster than I could click.
> The file in question (see screenshot) looks normal to me. It has the correct 
> owner and permissions and its content is this:
> count=1000
>  MTTF=71985
>  uihandler.preferences.writable.check=1608633016127
> The crash happened directly after starting the IDE, while it was reading in 
> the last project I worked on. No user interaction was involved.
> Fedora 29 / KDE.



--
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-5177) Crash: cannot get exclusive access to uihandler.properties

2021-01-09 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-5177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261959#comment-17261959
 ] 

Scott Palmer commented on NETBEANS-5177:


I'm getting these errors after working for a while with Gradle-based projects.  
My guess would be that NetBeans (or the JRE) is leaking file handles.
I'm running NetBeans 12.2 on macOS Big Sur 11.1
{{openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment Zulu15.28+51-CA (build 15.0.1+9)
OpenJDK 64-Bit Server VM Zulu15.28+51-CA (build 15.0.1+9, mixed mode, sharing)
}}

I never noticed anything like this prior to NB 12.2.

> Crash: cannot get exclusive access to uihandler.properties
> --
>
> Key: NETBEANS-5177
> URL: https://issues.apache.org/jira/browse/NETBEANS-5177
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 12.2
>Reporter: Ulrich Mayring
>Priority: Blocker
> Attachments: messages.log, sc.png, screenshot2.png, thread_dump.rtf
>
>
> I experienced a number of total freezes after installing NB 12.2 (have been 
> using 12.0 before), but could not get an error message of any sort, since NB 
> was completely unresponsive to keystrokes or mouse. This changed today, I got 
> an error popup, which I attach. NB was again totally unresponsive, but I 
> could make a screenshot of the popup message.
> The black shadow around the error dialog actually is tens or hundreds of the 
> same popup windows behind the first one. They keep piling up at CPU speed 
> until the app runs out of memory or is killed. For a while I could close a 
> few of them, but they kept coming up faster than I could click.
> The file in question (see screenshot) looks normal to me. It has the correct 
> owner and permissions and its content is this:
> count=1000
>  MTTF=71985
>  uihandler.preferences.writable.check=1608633016127
> The crash happened directly after starting the IDE, while it was reading in 
> the last project I worked on. No user interaction was involved.
> Fedora 29 / KDE.



--
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-5118) Multiline string literals are highlighted incorrectly when they contain blank lines

2020-12-08 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-5118:
--

 Summary: Multiline string literals are highlighted incorrectly 
when they contain blank lines
 Key: NETBEANS-5118
 URL: https://issues.apache.org/jira/browse/NETBEANS-5118
 Project: NetBeans
  Issue Type: Bug
  Components: cnd - Editor
Affects Versions: 12.2
 Environment: Product Version: Apache NetBeans IDE 12.2
Java: 15.0.1; OpenJDK 64-Bit Server VM 15.0.1+9
Runtime: OpenJDK Runtime Environment 15.0.1+9
System: Windows 10 version 10.0 running on amd64; Cp1252; en_CA (nb)

Reporter: Scott Palmer
 Attachments: bad_highlight.png, correct_indent.png

According to the spec, (https://openjdk.java.net/jeps/378) blank lines are 
excluded from "determining lines" when calculating indentation to strip.

"Blank lines -- lines that are empty or are composed wholly of white space -- 
have no visible influence on the indentation."

NetBeans highlighting does not do this and highlights extra leading spaces as 
if they are included in the string when there are blank lines that are 
completely empty or contain less spaces than the correct indent amount.




--
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-1678) Option for coloring EOL

2020-12-07 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-1678:
---
Attachment: Whitespace_Colors_Screenshot.png

> Option for coloring EOL
> ---
>
> Key: NETBEANS-1678
> URL: https://issues.apache.org/jira/browse/NETBEANS-1678
> Project: NetBeans
>  Issue Type: New Feature
>  Components: editor - Options, editor - Painting  Printing
>Affects Versions: Next
>Reporter: Christian Lenz
>Priority: Major
> Attachments: Whitespace_Colors_Screenshot.png
>
>
> When I activate the option "Show non-printable characters" I can choose a 
> different color for Whitespace. Unfortunately this will not affect the EOL 
> symbol. It has still the same color as before. So it would be good, if we can 
> have an option to change the color for EOL for all languages too.
> See the external link, there are some more options to change the color for 
> that. Some other non-printable characters.
> Cheers
> Chris



--
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-1678) Option for coloring EOL

2020-12-07 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-1678:
---
Attachment: 2020-12-06.png

> Option for coloring EOL
> ---
>
> Key: NETBEANS-1678
> URL: https://issues.apache.org/jira/browse/NETBEANS-1678
> Project: NetBeans
>  Issue Type: New Feature
>  Components: editor - Options, editor - Painting  Printing
>Affects Versions: Next
>Reporter: Christian Lenz
>Priority: Major
>
> When I activate the option "Show non-printable characters" I can choose a 
> different color for Whitespace. Unfortunately this will not affect the EOL 
> symbol. It has still the same color as before. So it would be good, if we can 
> have an option to change the color for EOL for all languages too.
> See the external link, there are some more options to change the color for 
> that. Some other non-printable characters.
> Cheers
> Chris



--
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-1678) Option for coloring EOL

2020-12-07 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-1678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-1678:
---
Attachment: (was: 2020-12-06.png)

> Option for coloring EOL
> ---
>
> Key: NETBEANS-1678
> URL: https://issues.apache.org/jira/browse/NETBEANS-1678
> Project: NetBeans
>  Issue Type: New Feature
>  Components: editor - Options, editor - Painting  Printing
>Affects Versions: Next
>Reporter: Christian Lenz
>Priority: Major
>
> When I activate the option "Show non-printable characters" I can choose a 
> different color for Whitespace. Unfortunately this will not affect the EOL 
> symbol. It has still the same color as before. So it would be good, if we can 
> have an option to change the color for EOL for all languages too.
> See the external link, there are some more options to change the color for 
> that. Some other non-printable characters.
> Cheers
> Chris



--
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-2494) autocomplete deletes instead of completes

2020-06-02 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17124594#comment-17124594
 ] 

Scott Palmer commented on NETBEANS-2494:


I’m running the latest NB 12.0 beta (6?) on JDK 14 and I still frequently see 
that my Autocomplete selection fails to insert. 
Though I’ve been working on some code where the file will be full of parsing 
errors as I edit, I would still expect my selection to be inserted always.  
(I’m pasting in some Go code and the converting it to Java. )

> autocomplete deletes instead of completes
> -
>
> Key: NETBEANS-2494
> URL: https://issues.apache.org/jira/browse/NETBEANS-2494
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 11.0
> Environment: OS X 10.14.3 (18D109)
> Java 1.8.0_181
> Product Version: Apache NetBeans IDE 11.0 (Build 
> incubator-netbeans-release-404-on-20190319)
> Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13
> Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13
> System: Mac OS X version 10.14.3 running on x86_64; UTF-8; en_US (nb)
> User directory: ~/Library/Application Support/NetBeans/11.0
> Cache directory: ~/Library/Caches/NetBeans/11.0
>Reporter: Paul
>Priority: Critical
> Attachments: Test.java
>
>
> easily reproducible (on Mac anyway).
> In any java class, inside method body type this:
>  
> OutputStream os = new ByteArra
> then press Ctrl-Space, press down-cursor to go to 
> java.io.ByteArrayOutputStream constructor., press Enter.
> Instead of completing as requestedor offering user input to choose what to 
> actually put there, NB11 deletes the new ByteArra.
> The only way to get it to actually complete is mouse-click.
> Super-long time NB user here - grew accustomed to a pleasurable dev 
> experience, and loss of this functionality is so taxing it's worth just using 
> Eclipse at this point.
>  
> Looking forward to a fix
>  
> Related: NETBEANS-2490



--
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-4301) Multiline string literals show with wrong background colour when using dark LAF

2020-05-04 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17099250#comment-17099250
 ] 

Scott Palmer commented on NETBEANS-4301:


At first I wondered if we needed that colour as well, but I believe we do.

The key is that it shows you were the beginning of each line actually is, so 
you know what amount of whitespace is trimmed from the start of the lines.  
This makes it easy to identify a misaligned closing """.

> Multiline string literals show with wrong background colour when using dark 
> LAF
> ---
>
> Key: NETBEANS-4301
> URL: https://issues.apache.org/jira/browse/NETBEANS-4301
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 11.3
> Environment: Windows 10 Pro
> Java 14.0.1
>Reporter: Scott Palmer
>Priority: Major
>  Labels: Look
> Attachments: image-2020-05-04-23-52-17-918.png
>
>
> Using the new multiline strings literals in JDK-14 with a dark look and feel 
> like either "Dark Nimbis" or "FlatLaf Dark" on Windows 10, the text in the 
> multiline string has a white background.



--
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-4301) Multiline string literals show with wrong background colour when using dark LAF

2020-05-04 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17099250#comment-17099250
 ] 

Scott Palmer edited comment on NETBEANS-4301 at 5/4/20, 6:51 PM:
-

At first I wondered if we needed that colour as well, but I believe we do.

The key is that it shows you where the beginning of each line actually is, so 
you know what amount of whitespace is trimmed from the start of the lines.  
This makes it easy to identify a misaligned closing """.


was (Author: swpalmer):
At first I wondered if we needed that colour as well, but I believe we do.

The key is that it shows you were the beginning of each line actually is, so 
you know what amount of whitespace is trimmed from the start of the lines.  
This makes it easy to identify a misaligned closing """.

> Multiline string literals show with wrong background colour when using dark 
> LAF
> ---
>
> Key: NETBEANS-4301
> URL: https://issues.apache.org/jira/browse/NETBEANS-4301
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 11.3
> Environment: Windows 10 Pro
> Java 14.0.1
>Reporter: Scott Palmer
>Priority: Major
>  Labels: Look
> Attachments: image-2020-05-04-23-52-17-918.png
>
>
> Using the new multiline strings literals in JDK-14 with a dark look and feel 
> like either "Dark Nimbis" or "FlatLaf Dark" on Windows 10, the text in the 
> multiline string has a white background.



--
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-4301) Multiline string literals show with wrong background colour when using dark LAF

2020-05-02 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-4301:
--

 Summary: Multiline string literals show with wrong background 
colour when using dark LAF
 Key: NETBEANS-4301
 URL: https://issues.apache.org/jira/browse/NETBEANS-4301
 Project: NetBeans
  Issue Type: Bug
  Components: java - Editor
Affects Versions: 11.3
 Environment: Windows 10 Pro
Java 14.0.1
Reporter: Scott Palmer


Using the new multiline strings literals in JDK-14 with a dark look and feel 
like either "Dark Nimbis" or "FlatLaf Dark" on Windows 10, the text in the 
multiline string has a white background.



--
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-4198) Bad text rendering for Test results on macOS

2020-04-19 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-4198:
--

 Summary: Bad text rendering for Test results on macOS
 Key: NETBEANS-4198
 URL: https://issues.apache.org/jira/browse/NETBEANS-4198
 Project: NetBeans
  Issue Type: Bug
  Components: utilities - Test Runner
Affects Versions: 11.3
Reporter: Scott Palmer
 Attachments: bad test text.jpg

The message “Tests passed: XX%” is poorly rendered.  It’s like the alpha 
channel is blending in a binary way.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Updated] (NETBEANS-4198) Bad text rendering for Test results on macOS

2020-04-19 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-4198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-4198:
---
Attachment: bad test text.jpg

> Bad text rendering for Test results on macOS
> 
>
> Key: NETBEANS-4198
> URL: https://issues.apache.org/jira/browse/NETBEANS-4198
> Project: NetBeans
>  Issue Type: Bug
>  Components: utilities - Test Runner
>Affects Versions: 11.3
>Reporter: Scott Palmer
>Priority: Minor
> Attachments: bad test text.jpg
>
>
> The message “Tests passed: XX%” is poorly rendered.  It’s like the alpha 
> channel is blending in a binary way.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists



[jira] [Comment Edited] (NETBEANS-4126) Tasks on Sub-projects of a Gradle build are invoked by changing to the sub-project directory first, this can change the project hierarchy

2020-04-06 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076700#comment-17076700
 ] 

Scott Palmer edited comment on NETBEANS-4126 at 4/6/20, 9:46 PM:
-

I won't deny that the setup is a bit... unconventional.  

This is a project that started before Gradle had the concept of Composite 
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which 
would likely have been the better way to go had it been available at the time.  
Instead, I have a set of libraries with some dependencies between them.  All of 
them are part of a framework that is delivered as a rather hefty SDK.  It is 
useful during development to have these libraries behave as peer projects in a 
multi-project build as changes to LibraryA are developed alongside 
corresponding changes to LibraryB, so using project(':LibraryA') style 
dependencies makes everything build smoothly from the root project.  However, 
each library is released as a separate JAR with it's own version.

When we do a release of an individual sub-project we run the build from within 
the sub-project.  For that purpose the library only depends on other released 
libraries.  The build logic handles the dependencies, automatically flipping 
from peer projects when building from the root, to explicitly versioned 
releases of the peer libraries when building from within a particular 
sub-project.  Since the working copy is always in a -SNAPSHOT state for each 
library, the release build does not work using peer projects as dependencies, 
because -SNAPSHOT dependencies are not allowed in a release.

So day-to-day development is done with the projects behaving as peers in a 
multi-project build, with inter-project dependencies, but releases are built 
with the sub-projects behaving as root projects with dependencies being the 
latest release of the peers, referenced as normal dependencies.

I may seem like an anti-pattern, and perhaps it is, but it was working well and 
really sped up development not having to explicitly build new snapshots of 
dependencies all the time.  So we didn't take on the job of converting our root 
project to use composite builds instead, and lose the ability to build a 
subproject and have it automatically build any peer dependencies that needed to 
be built.

Edit: I should note that we used to build the sub-projects with the -u option 
when doing a release, until it was deprecated.  So initially the sub-projects 
didn't have settings.gradle files.  Those were added to workaround the 
deprecation of the -u option at a later time.


was (Author: swpalmer):
I won't deny that the setup is a bit... unconventional.  

This is a project that started before Gradle had the concept of Composite 
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which 
would likely have been the better way to go had it been available at the time.  
Instead, I have a set of libraries with some dependencies between them.  All of 
them are part of a framework that is delivered as a rather hefty SDK.  It is 
useful during development to have these libraries behave as peer projects in a 
multi-project build as changes to LibraryA are developed alongside 
corresponding changes to LibraryB, so using project(':LibraryA') style 
dependencies makes everything build smoothly from the root project.  However, 
each library is released as a separate JAR with it's own version.

When we do a release of an individual sub-project we run the build from within 
the sub-project.  For that purpose the library only depends on other released 
libraries.  The build logic handles the dependencies, automatically flipping 
from peer projects when building from the root, to explicitly versioned 
releases of the peer libraries when building from within a particular 
sub-project.  Since the working copy is always in a -SNAPSHOT state for each 
library, the release build does not work using peer projects as dependencies, 
because -SNAPSHOT dependencies are not allowed in a release.

So day-to-day development is done with the projects behaving as peers in a 
multi-project build, with inter-project dependencies, but releases are built 
with the sub-projects behaving as root projects with dependencies being the 
latest release of the peers, referenced as normal dependencies.

I may seem like an anti-pattern, and perhaps it is, but it was working well and 
really sped up development not having to explicitly build new snapshots of 
dependencies all the time.  So we didn't take on the job of converting our root 
project to use composite builds instead, and lose the ability to build a 
subproject and have it automatically build any peer dependencies that needed to 
be built.

Edit: I should note that we used to build the sub-projects with the -u option, 
until it was deprecated.  So initially the sub-projects didn't have 

[jira] [Comment Edited] (NETBEANS-4126) Tasks on Sub-projects of a Gradle build are invoked by changing to the sub-project directory first, this can change the project hierarchy

2020-04-06 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076700#comment-17076700
 ] 

Scott Palmer edited comment on NETBEANS-4126 at 4/6/20, 9:45 PM:
-

I won't deny that the setup is a bit... unconventional.  

This is a project that started before Gradle had the concept of Composite 
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which 
would likely have been the better way to go had it been available at the time.  
Instead, I have a set of libraries with some dependencies between them.  All of 
them are part of a framework that is delivered as a rather hefty SDK.  It is 
useful during development to have these libraries behave as peer projects in a 
multi-project build as changes to LibraryA are developed alongside 
corresponding changes to LibraryB, so using project(':LibraryA') style 
dependencies makes everything build smoothly from the root project.  However, 
each library is released as a separate JAR with it's own version.

When we do a release of an individual sub-project we run the build from within 
the sub-project.  For that purpose the library only depends on other released 
libraries.  The build logic handles the dependencies, automatically flipping 
from peer projects when building from the root, to explicitly versioned 
releases of the peer libraries when building from within a particular 
sub-project.  Since the working copy is always in a -SNAPSHOT state for each 
library, the release build does not work using peer projects as dependencies, 
because -SNAPSHOT dependencies are not allowed in a release.

So day-to-day development is done with the projects behaving as peers in a 
multi-project build, with inter-project dependencies, but releases are built 
with the sub-projects behaving as root projects with dependencies being the 
latest release of the peers, referenced as normal dependencies.

I may seem like an anti-pattern, and perhaps it is, but it was working well and 
really sped up development not having to explicitly build new snapshots of 
dependencies all the time.  So we didn't take on the job of converting our root 
project to use composite builds instead, and lose the ability to build a 
subproject and have it automatically build any peer dependencies that needed to 
be built.

Edit: I should note that we used to build the sub-projects with the -u option, 
until it was deprecated.  So initially the sub-projects didn't have 
settings.gradle files.  Those were added to workaround the deprecation of the 
-u option at a later time.


was (Author: swpalmer):
I won't deny that the setup is a bit... unconventional.  

This is a project that started before Gradle had the concept of Composite 
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which 
would likely have been the better way to go had it been available at the time.  
Instead, I have a set of libraries with some dependencies between them.  All of 
them are part of a framework that is delivered as a rather hefty SDK.  It is 
useful during development to have these libraries behave as peer projects in a 
multi-project build as changes to LibraryA are developed alongside 
corresponding changes to LibraryB, so using project(':LibraryA') style 
dependencies makes everything build smoothly from the root project.  However, 
each library is released as a separate JAR with it's own version.

When we do a release of an individual sub-project we run the build from within 
the sub-project.  For that purpose the library only depends on other released 
libraries.  The build logic handles the dependencies, automatically flipping 
from peer projects when building from the root, to explicitly versioned 
releases of the peer libraries when building from within a particular 
sub-project.  Since the working copy is always in a -SNAPSHOT state for each 
library, the release build does not work using peer projects as dependencies, 
because -SNAPSHOT dependencies are not allowed in a release.

So day-to-day development is done with the projects behaving as peers in a 
multi-project build, with inter-project dependencies, but releases are built 
with the sub-projects behaving as root projects with dependencies being the 
latest release of the peers, referenced as normal dependencies.

I may seem like an anti-pattern, and perhaps it is, but it was working well and 
really sped up development not having to explicitly build new snapshots of 
dependencies all the time.  So we didn't take on the job of converting our root 
project to use composite builds instead, and lose the ability to build a 
subproject and have it automatically build any peer dependencies that needed to 
be built.

> Tasks on Sub-projects of a Gradle build are invoked by changing to the 
> sub-project directory first, this can change the project hierarchy
> 

[jira] [Commented] (NETBEANS-4126) Tasks on Sub-projects of a Gradle build are invoked by changing to the sub-project directory first, this can change the project hierarchy

2020-04-06 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-4126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17076700#comment-17076700
 ] 

Scott Palmer commented on NETBEANS-4126:


I won't deny that the setup is a bit... unconventional.  

This is a project that started before Gradle had the concept of Composite 
Builds (https://docs.gradle.org/current/userguide/composite_builds.html), which 
would likely have been the better way to go had it been available at the time.  
Instead, I have a set of libraries with some dependencies between them.  All of 
them are part of a framework that is delivered as a rather hefty SDK.  It is 
useful during development to have these libraries behave as peer projects in a 
multi-project build as changes to LibraryA are developed alongside 
corresponding changes to LibraryB, so using project(':LibraryA') style 
dependencies makes everything build smoothly from the root project.  However, 
each library is released as a separate JAR with it's own version.

When we do a release of an individual sub-project we run the build from within 
the sub-project.  For that purpose the library only depends on other released 
libraries.  The build logic handles the dependencies, automatically flipping 
from peer projects when building from the root, to explicitly versioned 
releases of the peer libraries when building from within a particular 
sub-project.  Since the working copy is always in a -SNAPSHOT state for each 
library, the release build does not work using peer projects as dependencies, 
because -SNAPSHOT dependencies are not allowed in a release.

So day-to-day development is done with the projects behaving as peers in a 
multi-project build, with inter-project dependencies, but releases are built 
with the sub-projects behaving as root projects with dependencies being the 
latest release of the peers, referenced as normal dependencies.

I may seem like an anti-pattern, and perhaps it is, but it was working well and 
really sped up development not having to explicitly build new snapshots of 
dependencies all the time.  So we didn't take on the job of converting our root 
project to use composite builds instead, and lose the ability to build a 
subproject and have it automatically build any peer dependencies that needed to 
be built.

> Tasks on Sub-projects of a Gradle build are invoked by changing to the 
> sub-project directory first, this can change the project hierarchy
> -
>
> Key: NETBEANS-4126
> URL: https://issues.apache.org/jira/browse/NETBEANS-4126
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 11.3
> Environment: macOS 10.15.4
> Gradle 6.3
> NetBeans 11.3 running on JDK-14
> Project configured to compile with JDK-8
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> I have a multi-project Gradle project with a parent project and several 
> sub-projects.  However, in the sub-project folders I have a settings.gradle 
> file, so if gradle is invoked from within the sub-folder the sub-project 
> behaves as a root project.  This is intentional.
> When I open the parent project in NetBeans, the sub-projects are correctly 
> identified as belong to the parent project, but when build actions are done 
> on them the gradle command is invoked from the sub-folder, e.g.:
> JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"
> cd /Users/scott/dev/Kayak/MyParentProject/MySubProject; 
> /Users/scott/dev/gradle/bin/gradle --configure-on-demand -x check build
> Instead the build target should be augmented with the project path:
> JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"
> cd /Users/scott/dev/Kayak/MyParentProject; /Users/scott/dev/gradle/bin/gradle 
> --configure-on-demand -x check :MySubProject:build



--
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-4126) Tasks on Sub-projects of a Gradle build are invoked by changing to the sub-project directory first, this can change the project hierarchy

2020-04-06 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-4126:
--

 Summary: Tasks on Sub-projects of a Gradle build are invoked by 
changing to the sub-project directory first, this can change the project 
hierarchy
 Key: NETBEANS-4126
 URL: https://issues.apache.org/jira/browse/NETBEANS-4126
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Gradle
Affects Versions: 11.3
 Environment: macOS 10.15.4
Gradle 6.3
NetBeans 11.3 running on JDK-14
Project configured to compile with JDK-8
Reporter: Scott Palmer
Assignee: Laszlo Kishalmi


I have a multi-project Gradle project with a parent project and several 
sub-projects.  However, in the sub-project folders I have a settings.gradle 
file, so if gradle is invoked from within the sub-folder the sub-project 
behaves as a root project.  This is intentional.

When I open the parent project in NetBeans, the sub-projects are correctly 
identified as belong to the parent project, but when build actions are done on 
them the gradle command is invoked from the sub-folder, e.g.:

JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"
cd /Users/scott/dev/Kayak/MyParentProject/MySubProject; 
/Users/scott/dev/gradle/bin/gradle --configure-on-demand -x check build

Instead the build target should be augmented with the project path:

JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home"
cd /Users/scott/dev/Kayak/MyParentProject; /Users/scott/dev/gradle/bin/gradle 
--configure-on-demand -x check :MySubProject:build




--
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-3789) Configurations and dependencies occasionaly don't show for Gradle projects

2020-02-03 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17029219#comment-17029219
 ] 

Scott Palmer commented on NETBEANS-3789:


When the project was in the state mentioned in the description, and had been 
for an hour or so, I right-clicked on the "Configurations" node and selected 
"Download Javadoc". After that operation completed the "compile" configuration 
appeared with all the dependencies (direct and transitive).


> Configurations and dependencies occasionaly don't show for Gradle projects
> --
>
> Key: NETBEANS-3789
> URL: https://issues.apache.org/jira/browse/NETBEANS-3789
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 11.3
> Environment: macOS 10.15
> JDK 13.0.2
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Expanding the Projects pane, I expect to see under Configurations the 
> configurations and dependencies related to my project.  Sometimes 
> Configurations is empty, other times it is only partially filled in, yet 
> other times it appears to be complete.
> Example build.gradle:
> {code:java}
> apply plugin: 'java'
> apply plugin: 'jacoco'
> apply plugin: 'application'
> group = 'my.company'
> mainClassName = 'my.company.Main'
> repositories {
> mavenCentral()
> jcenter()
> mavenLocal()
> }
> dependencies {
> compile 'org.jitsi:libjitsi:1.0-SNAPSHOT' // built and in mavenLocal cache
> testCompile 'junit:junit:4.12'
> }
> {code}
> //
> In the above project only the testCompile configuration is shown.  For that 
> configuration dependencies hamcrest-core:1.3 and junit:4.12 were shown.  The 
> other dependency, libjitsi, was not shown at all, nor was the "compile" 
> configuration.



--
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-3789) Configurations and dependencies occasionaly don't show for Gradle projects

2020-02-03 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-3789:
---
Description: 
Expanding the Projects pane, I expect to see under Configurations the 
configurations and dependencies related to my project.  Sometimes 
Configurations is empty, other times it is only partially filled in, yet other 
times it appears to be complete.

Example build.gradle:


{code:java}
apply plugin: 'java'
apply plugin: 'jacoco'
apply plugin: 'application'

group = 'my.company'

mainClassName = 'my.company.Main'

repositories {
mavenCentral()
jcenter()
mavenLocal()
}

dependencies {
compile 'org.jitsi:libjitsi:1.0-SNAPSHOT' // built and in mavenLocal cache
testCompile 'junit:junit:4.12'
}
{code}


//

In the above project only the testCompile configuration is shown.  For that 
configuration dependencies hamcrest-core:1.3 and junit:4.12 were shown.  The 
other dependency, libjitsi, was not shown at all, nor was the "compile" 
configuration.

  was:
Expanding the Projects pane, I expect to see under Configurations the 
configurations and dependencies related to my project.  Sometimes 
Configurations is empty, other times it is only partially filled in, yet other 
times it appears to be complete.

Example build.gradle:

apply plugin: 'java'
apply plugin: 'jacoco'
apply plugin: 'application'

group = 'my.company'

mainClassName = 'my.company.Main'

repositories {
mavenCentral()
jcenter()
mavenLocal()
}

dependencies {
compile 'org.jitsi:libjitsi:1.0-SNAPSHOT' // built and in mavenLocal cache
testCompile 'junit:junit:4.12'
}

//

In the above project only the testCompile configuration is shown.  For that 
configuration dependencies hamcrest-core:1.3 and junit:4.12 were shown.  The 
other dependency, libjitsi, was not shown at all, nor was the "compile" 
configuration.


> Configurations and dependencies occasionaly don't show for Gradle projects
> --
>
> Key: NETBEANS-3789
> URL: https://issues.apache.org/jira/browse/NETBEANS-3789
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 11.3
> Environment: macOS 10.15
> JDK 13.0.2
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Expanding the Projects pane, I expect to see under Configurations the 
> configurations and dependencies related to my project.  Sometimes 
> Configurations is empty, other times it is only partially filled in, yet 
> other times it appears to be complete.
> Example build.gradle:
> {code:java}
> apply plugin: 'java'
> apply plugin: 'jacoco'
> apply plugin: 'application'
> group = 'my.company'
> mainClassName = 'my.company.Main'
> repositories {
> mavenCentral()
> jcenter()
> mavenLocal()
> }
> dependencies {
> compile 'org.jitsi:libjitsi:1.0-SNAPSHOT' // built and in mavenLocal cache
> testCompile 'junit:junit:4.12'
> }
> {code}
> //
> In the above project only the testCompile configuration is shown.  For that 
> configuration dependencies hamcrest-core:1.3 and junit:4.12 were shown.  The 
> other dependency, libjitsi, was not shown at all, nor was the "compile" 
> configuration.



--
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-3789) Configurations and dependencies occasionaly don't show fo Gradle projects

2020-02-03 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-3789:
--

 Summary: Configurations and dependencies occasionaly don't show fo 
Gradle projects
 Key: NETBEANS-3789
 URL: https://issues.apache.org/jira/browse/NETBEANS-3789
 Project: NetBeans
  Issue Type: Bug
  Components: projects - Gradle
Affects Versions: 11.3
 Environment: macOS 10.15
JDK 13.0.2
Reporter: Scott Palmer
Assignee: Laszlo Kishalmi


Expanding the Projects pane, I expect to see under Configurations the 
configurations and dependencies related to my project.  Sometimes 
Configurations is empty, other times it is only partially filled in, yet other 
times it appears to be complete.

Example build.gradle:

apply plugin: 'java'
apply plugin: 'jacoco'
apply plugin: 'application'

group = 'my.company'

mainClassName = 'my.company.Main'

repositories {
mavenCentral()
jcenter()
mavenLocal()
}

dependencies {
compile 'org.jitsi:libjitsi:1.0-SNAPSHOT' // built and in mavenLocal cache
testCompile 'junit:junit:4.12'
}

//

In the above project only the testCompile configuration is shown.  For that 
configuration dependencies hamcrest-core:1.3 and junit:4.12 were shown.  The 
other dependency, libjitsi, was not shown at all, nor was the "compile" 
configuration.



--
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-3789) Configurations and dependencies occasionaly don't show for Gradle projects

2020-02-03 Thread Scott Palmer (Jira)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-3789:
---
Summary: Configurations and dependencies occasionaly don't show for Gradle 
projects  (was: Configurations and dependencies occasionaly don't show fo 
Gradle projects)

> Configurations and dependencies occasionaly don't show for Gradle projects
> --
>
> Key: NETBEANS-3789
> URL: https://issues.apache.org/jira/browse/NETBEANS-3789
> Project: NetBeans
>  Issue Type: Bug
>  Components: projects - Gradle
>Affects Versions: 11.3
> Environment: macOS 10.15
> JDK 13.0.2
>Reporter: Scott Palmer
>Assignee: Laszlo Kishalmi
>Priority: Major
>
> Expanding the Projects pane, I expect to see under Configurations the 
> configurations and dependencies related to my project.  Sometimes 
> Configurations is empty, other times it is only partially filled in, yet 
> other times it appears to be complete.
> Example build.gradle:
> apply plugin: 'java'
> apply plugin: 'jacoco'
> apply plugin: 'application'
> group = 'my.company'
> mainClassName = 'my.company.Main'
> repositories {
> mavenCentral()
> jcenter()
> mavenLocal()
> }
> dependencies {
> compile 'org.jitsi:libjitsi:1.0-SNAPSHOT' // built and in mavenLocal cache
> testCompile 'junit:junit:4.12'
> }
> //
> In the above project only the testCompile configuration is shown.  For that 
> configuration dependencies hamcrest-core:1.3 and junit:4.12 were shown.  The 
> other dependency, libjitsi, was not shown at all, nor was the "compile" 
> configuration.



--
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-3329) Exception loading OpenJFX gradle project

2019-11-03 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965661#comment-16965661
 ] 

Scott Palmer commented on NETBEANS-3329:


Oh, you are testing on Linux. I’ve never attempted to build on Linux, just 
macOS.  The build instructions are on the OpenJFX wiki page: 
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX


> Exception loading OpenJFX gradle project
> 
>
> Key: NETBEANS-3329
> URL: https://issues.apache.org/jira/browse/NETBEANS-3329
> Project: NetBeans
>  Issue Type: Bug
> Environment: macOS 10.15
> JDK 12.0.2
>Reporter: Scott Palmer
>Priority: Major
> Attachments: messages.log
>
>
> Loading the OpenJFX project and then the "controls" sub-project lead to 
> exceptions and the controls project showing red error markers.
>  IDE log attached.
>  



--
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-3329) Exception loading OpenJFX gradle project

2019-11-02 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965542#comment-16965542
 ] 

Scott Palmer commented on NETBEANS-3329:


Info from the NetBEans About dialog, for the record:

Product Version: Apache NetBeans IDE 11.2
Java: 12.0.2; OpenJDK 64-Bit Server VM 12.0.2+10
Runtime: OpenJDK Runtime Environment 12.0.2+10
System: Mac OS X version 10.15.1 running on x86_64; UTF-8; en_CA (nb)
User directory: /Users/scott/Library/Application Support/NetBeans/11.2
Cache directory: /Users/scott/Library/Caches/NetBeans/11.2


> Exception loading OpenJFX gradle project
> 
>
> Key: NETBEANS-3329
> URL: https://issues.apache.org/jira/browse/NETBEANS-3329
> Project: NetBeans
>  Issue Type: Bug
> Environment: macOS 10.15
> JDK 12.0.2
>Reporter: Scott Palmer
>Priority: Major
> Attachments: messages.log
>
>
> Loading the OpenJFX project and then the "controls" sub-project lead to 
> exceptions and the controls project showing red error markers.
>  IDE log attached.
>  



--
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-3329) Exception loading OpenJFX gradle project

2019-11-02 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965539#comment-16965539
 ] 

Scott Palmer edited comment on NETBEANS-3329 at 11/3/19 2:12 AM:
-

[~GeertjanWielenga]  This has nothing to do with developing *with* OpenJFX .   
I'm not talking about making an OpenJFX-based application.  I'm talking about 
building the JavaFX framework itself, from the existing project sources.  The 
OpenJFX project uses Gradle. 
This issue involves using NetBeans to work on existing Gradle-based projects. 
In this context, OpenJFX is just representative of a large open-source project 
that uses Gradle that I would like to work on with an IDE, like NetBeans.  
It's a publicly available project that can be used to reproduce issues with 
NetBeans + Gradle.  I believe many of the issues are already known, but I don't 
think this particular exception was reported earlier.

[~lkishalmi] What issue did you encounter building from the command line?  Did 
you use gradlew?  The JDK must be JDK 12 as OpenJFX does not build with JDK 13 
yet.


was (Author: swpalmer):
[~GeertjanWielenga]  This has nothing to do with developing *with* OpenJFX .   
I'm not talking about making an OpenJFX-based application.  I'm talking about 
building the JavaFX framework itself, from the existing project sources.  The 
OpenJFX project uses Gradle. 
This issue involves using NetBeans to work on existing Gradle-based projects. 
In this context, OpenJFX is just representative of a large open-source project 
that uses Gradle that I would like to work on with an IDE, like NetBeans.  
It's a publicly available project that can be used to reproduce issues with 
NetBeans + Gradle.  I believe many of the issues are already known, but I don't 
think this particular exception was reported earlier.

[~lkishalmi] What issue did you encounter building from the command line?  Did 
you using gradlew?  The JDK must be JDK 12 as OpenJFX does not build with JDK 
13 yet.

> Exception loading OpenJFX gradle project
> 
>
> Key: NETBEANS-3329
> URL: https://issues.apache.org/jira/browse/NETBEANS-3329
> Project: NetBeans
>  Issue Type: Bug
> Environment: macOS 10.15
> JDK 12.0.2
>Reporter: Scott Palmer
>Priority: Major
> Attachments: messages.log
>
>
> Loading the OpenJFX project and then the "controls" sub-project lead to 
> exceptions and the controls project showing red error markers.
>  IDE log attached.
>  



--
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-3329) Exception loading OpenJFX gradle project

2019-11-02 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965539#comment-16965539
 ] 

Scott Palmer commented on NETBEANS-3329:


[~GeertjanWielenga]  This has nothing to do with developing *with* OpenJFX .   
I'm not talking about making an OpenJFX-based application.  I'm talking about 
building the JavaFX framework itself, from the existing project sources.  The 
OpenJFX project uses Gradle. 
This issue involves using NetBeans to work on existing Gradle-based projects. 
In this context, OpenJFX is just representative of a large open-source project 
that uses Gradle that I would like to work on with an IDE, like NetBeans.  
It's a publicly available project that can be used to reproduce issues with 
NetBeans + Gradle.  I believe many of the issues are already known, but I don't 
think this particular exception was reported earlier.

[~lkishalmi] What issue did you encounter building from the command line?  Did 
you using gradlew?  The JDK must be JDK 12 as OpenJFX does not build with JDK 
13 yet.

> Exception loading OpenJFX gradle project
> 
>
> Key: NETBEANS-3329
> URL: https://issues.apache.org/jira/browse/NETBEANS-3329
> Project: NetBeans
>  Issue Type: Bug
> Environment: macOS 10.15
> JDK 12.0.2
>Reporter: Scott Palmer
>Priority: Major
> Attachments: messages.log
>
>
> Loading the OpenJFX project and then the "controls" sub-project lead to 
> exceptions and the controls project showing red error markers.
>  IDE log attached.
>  



--
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-3329) Exception loading OpenJFX gradle project

2019-11-02 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965501#comment-16965501
 ] 

Scott Palmer edited comment on NETBEANS-3329 at 11/2/19 9:04 PM:
-

OpenJFX is where JavaFX lives since being separated from the JDK.  
https://openjfx.io


Specifically, clone this: https://github.com/openjdk/jfx.git

Then open the root project in NetBeans

Expand the subprojects folder in the projects pane and double click on 
jfx:controls or jfx:graphics to open the sub-projects.


Scott


was (Author: swpalmer):
OpenJFX is where JavaFX lives since being separated from the JDK.  
https://openjfx.io


Specifically, clone this: https://github.com/openjdk/jfx.git

Then open the root project in NetBeans

Expand the subprojects folder in the projects pane and double click on 
jfx:control or jfx:graphics to open the sub-projects.


Scott

> Exception loading OpenJFX gradle project
> 
>
> Key: NETBEANS-3329
> URL: https://issues.apache.org/jira/browse/NETBEANS-3329
> Project: NetBeans
>  Issue Type: Bug
> Environment: macOS 10.15
> JDK 12.0.2
>Reporter: Scott Palmer
>Priority: Major
> Attachments: messages.log
>
>
> Loading the OpenJFX project and then the "controls" sub-project lead to 
> exceptions and the controls project showing red error markers.
>  IDE log attached.
>  



--
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-3329) Exception loading OpenJFX gradle project

2019-11-02 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16965501#comment-16965501
 ] 

Scott Palmer commented on NETBEANS-3329:


OpenJFX is where JavaFX lives since being separated from the JDK.  
https://openjfx.io


Specifically, clone this: https://github.com/openjdk/jfx.git

Then open the root project in NetBeans

Expand the subprojects folder in the projects pane and double click on 
jfx:control or jfx:graphics to open the sub-projects.


Scott

> Exception loading OpenJFX gradle project
> 
>
> Key: NETBEANS-3329
> URL: https://issues.apache.org/jira/browse/NETBEANS-3329
> Project: NetBeans
>  Issue Type: Bug
> Environment: macOS 10.15
> JDK 12.0.2
>Reporter: Scott Palmer
>Priority: Major
> Attachments: messages.log
>
>
> Loading the OpenJFX project and then the "controls" sub-project lead to 
> exceptions and the controls project showing red error markers.
>  IDE log attached.
>  



--
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-3329) Exception loading OpenJFX gradle project

2019-11-02 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-3329:
--

 Summary: Exception loading OpenJFX gradle project
 Key: NETBEANS-3329
 URL: https://issues.apache.org/jira/browse/NETBEANS-3329
 Project: NetBeans
  Issue Type: Bug
 Environment: macOS 10.15
JDK 12.0.2
Reporter: Scott Palmer
 Attachments: messages.log

Loading the OpenJFX project and then the "controls" sub-project lead to 
exceptions and the controls project showing red error markers.
 IDE log attached.
 



--
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-3226) NetBeans fails silently if it can't attach a debugger

2019-10-09 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-3226:
--

 Summary: NetBeans fails silently if it can't attach a debugger
 Key: NETBEANS-3226
 URL: https://issues.apache.org/jira/browse/NETBEANS-3226
 Project: NetBeans
  Issue Type: Bug
  Components: debugger - Java
Affects Versions: 11.1, 11.2
Reporter: Scott Palmer


When trying to attach a debugger to an existing Java process, the operation 
simply does nothing if the attempt fails with no feedback to the user.

messages.log contains details, but note the odd repetition of the attach 
parameters in the log messages:

 

{{INFO [org.netbeans.api.debugger.jpda.AttachingDICookie]: Attaching Connector 
= com.sun.jdi.ProcessAttach (defaults: pid=, timeout=), arguments = 
\{pid=pid=14420, timeout=timeout=}INFO 
[org.netbeans.api.debugger.jpda.AttachingDICookie]: Attaching Connector = 
com.sun.jdi.ProcessAttach (defaults: pid=, timeout=), arguments = 
\{pid=pid=14420, timeout=timeout=}java.io.IOException: Access is denied at 
com.sun.tools.jdi.ProcessAttachingConnector.attach(ProcessAttachingConnector.java:104)[catch]
 at 
org.netbeans.api.debugger.jpda.AttachingDICookie.getVirtualMachine(AttachingDICookie.java:206)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider.doStartDebugger(StartActionProvider.java:163)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider.access$200(StartActionProvider.java:55)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider$1.run(StartActionProvider.java:140)
 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)INFO 
[org.netbeans.api.debugger.jpda.AttachingDICookie]: Attaching Connector = 
com.sun.jdi.SocketAttach (defaults: timeout=, hostname=DCM-Scott-01, port=), 
arguments = \{timeout=timeout=, hostname=hostname=DCM-Scott-01, 
port=port=8}java.net.ConnectException: Connection refused: connect at 
java.net.DualStackPlainSocketImpl.connect0(Native Method) at 
java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:79)
 at 
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at 
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
 at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) 
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) at 
java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) at 
java.net.Socket.connect(Socket.java:589) at 
com.sun.tools.jdi.SocketTransportService.attach(SocketTransportService.java:222)
 at 
com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:116)
 at 
com.sun.tools.jdi.SocketAttachingConnector.attach(SocketAttachingConnector.java:90)[catch]
 at 
org.netbeans.api.debugger.jpda.AttachingDICookie.getVirtualMachine(AttachingDICookie.java:206)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider.doStartDebugger(StartActionProvider.java:163)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider.access$200(StartActionProvider.java:55)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider$1.run(StartActionProvider.java:140)
 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)INFO 
[org.netbeans.api.debugger.jpda.AttachingDICookie]: Attaching Connector = 
com.sun.jdi.SocketAttach (defaults: timeout=, hostname=DCM-Scott-01, port=), 
arguments = \{timeout=timeout=1000, hostname=hostname=DCM-Scott-01, 
port=port=8}com.sun.jdi.connect.TransportTimeoutException: timed out trying 
to establish connection at 
com.sun.tools.jdi.SocketTransportService.attach(SocketTransportService.java:227)
 at 
com.sun.tools.jdi.GenericAttachingConnector.attach(GenericAttachingConnector.java:116)
 at 
com.sun.tools.jdi.SocketAttachingConnector.attach(SocketAttachingConnector.java:90)[catch]
 at 
org.netbeans.api.debugger.jpda.AttachingDICookie.getVirtualMachine(AttachingDICookie.java:206)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider.doStartDebugger(StartActionProvider.java:163)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider.access$200(StartActionProvider.java:55)
 at 
org.netbeans.modules.debugger.jpda.actions.StartActionProvider$1.run(StartActionProvider.java:140)
 at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1418) at 
org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:45) at 

[jira] [Commented] (NETBEANS-3217) Need better options for Tabs vs Spaces indenting.

2019-10-08 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-3217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946984#comment-16946984
 ] 

Scott Palmer commented on NETBEANS-3217:


A way to see the whitespace so you know when you are corrupting a file in this 
way would also be good.

> Need better options for Tabs vs Spaces indenting.
> -
>
> Key: NETBEANS-3217
> URL: https://issues.apache.org/jira/browse/NETBEANS-3217
> Project: NetBeans
>  Issue Type: Improvement
>  Components: editor - Formatting  Indentation
>Affects Versions: 11.1
>Reporter: Scott Palmer
>Priority: Major
>
> The current situation often leads to a mix of tabs and spaces ending up in 
> the same file if you switch between projects or files that don't match your 
> preference setting.
> !http://www.emacswiki.org/pics/static/TabsSpacesBoth.png!
> There seems to be no per-project setting or "smart" heuristic to simply adapt 
> to what the file currently has.



--
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-3217) Need better options for Tabs vs Spaces indenting.

2019-10-08 Thread Scott Palmer (Jira)
Scott Palmer created NETBEANS-3217:
--

 Summary: Need better options for Tabs vs Spaces indenting.
 Key: NETBEANS-3217
 URL: https://issues.apache.org/jira/browse/NETBEANS-3217
 Project: NetBeans
  Issue Type: Improvement
  Components: editor - Formatting  Indentation
Affects Versions: 11.1
Reporter: Scott Palmer


The current situation often leads to a mix of tabs and spaces ending up in the 
same file if you switch between projects or files that don't match your 
preference setting.

!http://www.emacswiki.org/pics/static/TabsSpacesBoth.png!

There seems to be no per-project setting or "smart" heuristic to simply adapt 
to what the file currently has.



--
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-2417) update Gradle logo/icon

2019-10-07 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16946473#comment-16946473
 ] 

Scott Palmer commented on NETBEANS-2417:


Are high DPI images included?

> update Gradle logo/icon
> ---
>
> Key: NETBEANS-2417
> URL: https://issues.apache.org/jira/browse/NETBEANS-2417
> Project: NetBeans
>  Issue Type: Improvement
>  Components: projects - Gradle
>Reporter: Jennifer Strater
>Assignee: Jennifer Strater
>Priority: Trivial
>  Labels: pull-request-available
> Attachments: Maven-Base-Is-Type-Overlay-Is-Maven.png, gradle1.png, 
> gradle2.png, image-2019-07-02-10-27-44-307.png, 
> image-2019-07-02-10-31-08-337.png, image-2019-07-02-10-33-19-023.png, 
> image-2019-07-02-10-49-16-797.png, image-2019-07-02-11-47-13-922.png, 
> image-2019-07-02-11-48-06-685.png, image-2019-07-02-11-49-01-655.png, 
> image-2019-07-02-11-50-09-232.png, image-2019-07-02-11-55-58-042.png, 
> image-2019-07-02-20-55-48-539.png, image-2019-10-07-19-58-12-859.png, 
> image-2019-10-07-19-58-34-360.png, image-2019-10-07-19-59-08-294.png, 
> image-2019-10-07-19-59-20-982.png, image-2019-10-07-19-59-37-293.png, 
> image-2019-10-07-20-00-15-046.png, image-2019-10-07-20-00-35-172.png, 
> nb1.png, nb2.png, nbIcons.png
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Thanks again for adding support for Gradle to Netbeans.
> The logo included in Netbeans for Gradle is the pre-2015 Gradleware logo. 
> We've recently published the newest Gradle elephant logos to 
> [https://gradle.com/brand/]. I'd be happy to help make this change if that's 
> easier for everyone.
> Please let me know how I should proceed.



--
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-2409) Very Slow Operations on Windows

2019-10-06 Thread Scott Palmer (Jira)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16945408#comment-16945408
 ] 

Scott Palmer commented on NETBEANS-2409:


It is certainly not worse, and I think it is improved.  Though I wouldn’t call 
it “quick”, I do not recall being angry waiting ages for NB to do something 
that appears trivial while on the beta. That was often the case with 11.1. 

> Very Slow  Operations on Windows
> 
>
> Key: NETBEANS-2409
> URL: https://issues.apache.org/jira/browse/NETBEANS-2409
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 10.0, 11.0
> Environment: Windows
>Reporter: Laszlo Kishalmi
>Priority: Critical
>  Labels: Performance, Windows
> Attachments: NB11_autocomplete.nps, NB11_getHint.nps, 
> WinFilesystemSlow.png
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> What is the best course of action for reporting slowness?  I can’t share my 
> project.
> I’m not certain how to give step-by-step instructions when the problem is 
> basically one step in most cases.  E.g. invoke auto-complete - nothing 
> happens for several seconds.  Invoke rename - dialog doesn’t appear for 
> several seconds.  Find usages - extremely slow > 5 second delay on a private 
> member of a class less than 100 lines.
> In general it seems NB 11 is noticeably slower than NB 8.2. Not good 
> considering slowness was already my #1 complaint about NB 8.2.  I have so far 
> found the benefits of NB outweigh the fact that it is much slower than other 
> IDEs for the same operations, but the slowness of NB 11 is tipping the scale. 
>  I don’t want to switch IDEs, pease don’t interpret this as some sort of 
> threat to do so. I would like to help find the issues in NB.  But I don’t 
> have the bandwidth to debug NB and not being about to share my project makes 
> it difficult to provide helpful reports :-(
> Are others seeing the slowness?
> Find usages, renames, call-hierarchy, auto-complete… things I use all the 
> time, I often have to wait 5 to 10 seconds for a response from the IDE, 
> sometimes more.
> I’ve already deleted user dir and cache and restarted. 
> I’m using Gradle-based Java projects, running NB 11.0 with JDK 8u202.



--
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-2494) autocomplete deletes instead of completes

2019-06-20 Thread Scott Palmer (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer updated NETBEANS-2494:
---
Attachment: Test.java

> autocomplete deletes instead of completes
> -
>
> Key: NETBEANS-2494
> URL: https://issues.apache.org/jira/browse/NETBEANS-2494
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 11.0
> Environment: OS X 10.14.3 (18D109)
> Java 1.8.0_181
> Product Version: Apache NetBeans IDE 11.0 (Build 
> incubator-netbeans-release-404-on-20190319)
> Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13
> Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13
> System: Mac OS X version 10.14.3 running on x86_64; UTF-8; en_US (nb)
> User directory: ~/Library/Application Support/NetBeans/11.0
> Cache directory: ~/Library/Caches/NetBeans/11.0
>Reporter: Paul
>Priority: Critical
> Attachments: Test.java
>
>
> easily reproducible (on Mac anyway).
> In any java class, inside method body type this:
>  
> OutputStream os = new ByteArra
> then press Ctrl-Space, press down-cursor to go to 
> java.io.ByteArrayOutputStream constructor., press Enter.
> Instead of completing as requestedor offering user input to choose what to 
> actually put there, NB11 deletes the new ByteArra.
> The only way to get it to actually complete is mouse-click.
> Super-long time NB user here - grew accustomed to a pleasurable dev 
> experience, and loss of this functionality is so taxing it's worth just using 
> Eclipse at this point.
>  
> Looking forward to a fix
>  
> Related: NETBEANS-2490



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2494) autocomplete deletes instead of completes

2019-06-20 Thread Scott Palmer (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868598#comment-16868598
 ] 

Scott Palmer commented on NETBEANS-2494:


It is very dependent on the surrounding code. Even doing something as simple as 
deleting an unused import can make it work, but if you undo to put back that 
import then it fails again... So whatever the specific criteria, it is 
reproducible.

 

I will attach a file that is causing this right now for me.  Test.java - try to 
autocomplete on like 17 after the . and choose charAt(int index) by pressing 
enter on the autocomplete pop-up.  For me it does not add the charAt() method 
call and will delete any prefix already typed (e.g. if you type 'cha' then 
ctrl-space, enter, you are back to nothing after the .

 

 

> autocomplete deletes instead of completes
> -
>
> Key: NETBEANS-2494
> URL: https://issues.apache.org/jira/browse/NETBEANS-2494
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 11.0
> Environment: OS X 10.14.3 (18D109)
> Java 1.8.0_181
> Product Version: Apache NetBeans IDE 11.0 (Build 
> incubator-netbeans-release-404-on-20190319)
> Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13
> Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13
> System: Mac OS X version 10.14.3 running on x86_64; UTF-8; en_US (nb)
> User directory: ~/Library/Application Support/NetBeans/11.0
> Cache directory: ~/Library/Caches/NetBeans/11.0
>Reporter: Paul
>Priority: Critical
> Attachments: Test.java
>
>
> easily reproducible (on Mac anyway).
> In any java class, inside method body type this:
>  
> OutputStream os = new ByteArra
> then press Ctrl-Space, press down-cursor to go to 
> java.io.ByteArrayOutputStream constructor., press Enter.
> Instead of completing as requestedor offering user input to choose what to 
> actually put there, NB11 deletes the new ByteArra.
> The only way to get it to actually complete is mouse-click.
> Super-long time NB user here - grew accustomed to a pleasurable dev 
> experience, and loss of this functionality is so taxing it's worth just using 
> Eclipse at this point.
>  
> Looking forward to a fix
>  
> Related: NETBEANS-2490



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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] [Resolved] (NETBEANS-2627) Autocomplete fail - delete the word

2019-06-20 Thread Scott Palmer (JIRA)


 [ 
https://issues.apache.org/jira/browse/NETBEANS-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Scott Palmer resolved NETBEANS-2627.

Resolution: Duplicate

Marking as duplicate.

> Autocomplete fail - delete the word 
> 
>
> Key: NETBEANS-2627
> URL: https://issues.apache.org/jira/browse/NETBEANS-2627
> Project: NetBeans
>  Issue Type: Bug
>  Components: cnd - Editor
>Reporter: Mohammad Mohsen Nourafkan
>Priority: Major
> Attachments: IDE Log.txt, UI Log.txt, n.png
>
>
> When I try to use autocomplete in the editor 
> the word  I typed half erase and the exception thrown
> an example: a static method of class A   \{A.staticMethod}
> I type A.stat   the editor propose  staticMethod but when I press enter it 
> erase 'stat' and only 'A.' 
> remain on the editor and throw an exception which I added at DOCS.text



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2494) autocomplete deletes instead of completes

2019-06-20 Thread Scott Palmer (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868581#comment-16868581
 ] 

Scott Palmer commented on NETBEANS-2494:


This appears to be a duplicate of NETBEANS-2627

> autocomplete deletes instead of completes
> -
>
> Key: NETBEANS-2494
> URL: https://issues.apache.org/jira/browse/NETBEANS-2494
> Project: NetBeans
>  Issue Type: Bug
>  Components: java - Editor
>Affects Versions: 11.0
> Environment: OS X 10.14.3 (18D109)
> Java 1.8.0_181
> Product Version: Apache NetBeans IDE 11.0 (Build 
> incubator-netbeans-release-404-on-20190319)
> Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13
> Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13
> System: Mac OS X version 10.14.3 running on x86_64; UTF-8; en_US (nb)
> User directory: ~/Library/Application Support/NetBeans/11.0
> Cache directory: ~/Library/Caches/NetBeans/11.0
>Reporter: Paul
>Priority: Critical
>
> easily reproducible (on Mac anyway).
> In any java class, inside method body type this:
>  
> OutputStream os = new ByteArra
> then press Ctrl-Space, press down-cursor to go to 
> java.io.ByteArrayOutputStream constructor., press Enter.
> Instead of completing as requestedor offering user input to choose what to 
> actually put there, NB11 deletes the new ByteArra.
> The only way to get it to actually complete is mouse-click.
> Super-long time NB user here - grew accustomed to a pleasurable dev 
> experience, and loss of this functionality is so taxing it's worth just using 
> Eclipse at this point.
>  
> Looking forward to a fix
>  
> Related: NETBEANS-2490



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2494) autocomplete deletes instead of completes

2019-06-20 Thread Scott Palmer (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16868578#comment-16868578
 ] 

Scott Palmer commented on NETBEANS-2494:


This is happening to me right now, and I've seen it before  Very frustrating.

 

Here's a bit from the IDE log:

 

SEVERE [global]
java.lang.AssertionError
 at com.sun.tools.javac.util.Assert.error(Assert.java:155)
 at com.sun.tools.javac.util.Assert.check(Assert.java:46)
 at com.sun.tools.javac.code.Scope$ScopeImpl.dble(Scope.java:410)
 at com.sun.tools.javac.code.Scope$ScopeImpl.enter(Scope.java:433)
 at com.sun.tools.javac.comp.MemberEnter.visitVarDef(MemberEnter.java:479)
 at 
com.sun.tools.javadoc.main.JavadocMemberEnter.visitVarDef(JavadocMemberEnter.java:84)
 at 
org.netbeans.lib.nbjavac.services.NBJavadocMemberEnter.visitVarDef(NBJavadocMemberEnter.java:92)
 at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:962)
 at com.sun.tools.javac.comp.MemberEnter.memberEnter(MemberEnter.java:172)
 at com.sun.tools.javac.comp.Attr.visitVarDef(Attr.java:1184)
 at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:962)
 at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:673)
 at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:749)
 at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:773)
 at com.sun.tools.javac.comp.Attr.visitBlock(Attr.java:1350)
 at org.netbeans.lib.nbjavac.services.NBAttr.visitBlock(NBAttr.java:78)
 at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1026)
 at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:673)
 at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:749)
 at 
org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:880)
 at 
org.netbeans.api.java.source.TreeUtilities.attributeTree(TreeUtilities.java:810)
 at 
org.netbeans.modules.editor.java.JavaCodeTemplateProcessor.type(JavaCodeTemplateProcessor.java:716)
 at 
org.netbeans.modules.editor.java.JavaCodeTemplateProcessor.instanceOf(JavaCodeTemplateProcessor.java:548)
 at 
org.netbeans.modules.editor.java.JavaCodeTemplateProcessor.getProposedValue(JavaCodeTemplateProcessor.java:397)
 at 
org.netbeans.modules.editor.java.JavaCodeTemplateProcessor.updateDefaultValues(JavaCodeTemplateProcessor.java:143)
 at 
org.netbeans.lib.editor.codetemplates.CodeTemplateInsertHandler.processTemplate(CodeTemplateInsertHandler.java:225)
 at 
org.netbeans.lib.editor.codetemplates.CodeTemplateManagerOperation.insert(CodeTemplateManagerOperation.java:273)
 at 
org.netbeans.lib.editor.codetemplates.api.CodeTemplate.insert(CodeTemplate.java:82)
 at 
org.netbeans.modules.editor.java.JavaCompletionItem.process(JavaCompletionItem.java:566)
 at 
org.netbeans.modules.editor.java.JavaCompletionItem.defaultAction(JavaCompletionItem.java:286)
 at 
org.netbeans.modules.editor.completion.CompletionImpl.dispatchKeyEvent(CompletionImpl.java:785)
 at 
org.netbeans.modules.editor.completion.CompletionImpl.keyPressed(CompletionImpl.java:386)
 at 
java.desktop/java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:258)
 at 
java.desktop/java.awt.AWTEventMulticaster.keyPressed(AWTEventMulticaster.java:257)
 at java.desktop/java.awt.Component.processKeyEvent(Component.java:6590)
 at java.desktop/javax.swing.JComponent.processKeyEvent(JComponent.java:2849)
 at java.desktop/java.awt.Component.processEvent(Component.java:6409)
 at java.desktop/java.awt.Container.processEvent(Container.java:2263)
 at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:5008)
 at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
 at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
 at 
java.desktop/java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1950)
 at 
java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:870)
 at 
java.desktop/java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1139)
 at 
java.desktop/java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:1009)
 at 
java.desktop/java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:835)
 at java.desktop/java.awt.Component.dispatchEventImpl(Component.java:4889)
 at java.desktop/java.awt.Container.dispatchEventImpl(Container.java:2321)
 at java.desktop/java.awt.Window.dispatchEventImpl(Window.java:2762)
 at java.desktop/java.awt.Component.dispatchEvent(Component.java:4840)
 at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:772)
 at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
 at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
 at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:389)
 at 
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
 at 

[jira] [Comment Edited] (NETBEANS-2409) Very Slow Operations on Windows

2019-04-23 Thread Scott Palmer (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824147#comment-16824147
 ] 

Scott Palmer edited comment on NETBEANS-2409 at 4/23/19 1:41 PM:
-

[~lkishalmi] that installer does not appear to be signed by a trusted source.  
When I attempted to open it Windows Defender warned me:

 
 Windows protected your PC
 Windows Defender SmartScreen prevented an unrecognized app from starting. 
Running this app might put your PC at risk.
|App:|Apache-NetBeans-11.0-bin-windows-x64.exe|
|Publisher: |Unknown publisher|


was (Author: swpalmer):
[~lkishalmi] that installer does not appear to be signed by a trusted source.  
When I attempted to open it Windows Defender warned me:

 
Windows protected your PC
Windows Defender SmartScreen prevented an unrecognized app from starting. 
Running this app might put your PC at risk.
[More info|about:blank#]

> Very Slow  Operations on Windows
> 
>
> Key: NETBEANS-2409
> URL: https://issues.apache.org/jira/browse/NETBEANS-2409
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 10.0, 11.0
> Environment: Windows
>Reporter: Laszlo Kishalmi
>Priority: Critical
>  Labels: Performance, Windows, pull-request-available
> Attachments: NB11_autocomplete.nps, NB11_getHint.nps, 
> WinFilesystemSlow.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> What is the best course of action for reporting slowness?  I can’t share my 
> project.
> I’m not certain how to give step-by-step instructions when the problem is 
> basically one step in most cases.  E.g. invoke auto-complete - nothing 
> happens for several seconds.  Invoke rename - dialog doesn’t appear for 
> several seconds.  Find usages - extremely slow > 5 second delay on a private 
> member of a class less than 100 lines.
> In general it seems NB 11 is noticeably slower than NB 8.2. Not good 
> considering slowness was already my #1 complaint about NB 8.2.  I have so far 
> found the benefits of NB outweigh the fact that it is much slower than other 
> IDEs for the same operations, but the slowness of NB 11 is tipping the scale. 
>  I don’t want to switch IDEs, pease don’t interpret this as some sort of 
> threat to do so. I would like to help find the issues in NB.  But I don’t 
> have the bandwidth to debug NB and not being about to share my project makes 
> it difficult to provide helpful reports :-(
> Are others seeing the slowness?
> Find usages, renames, call-hierarchy, auto-complete… things I use all the 
> time, I often have to wait 5 to 10 seconds for a response from the IDE, 
> sometimes more.
> I’ve already deleted user dir and cache and restarted. 
> I’m using Gradle-based Java projects, running NB 11.0 with JDK 8u202.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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-2409) Very Slow Operations on Windows

2019-04-23 Thread Scott Palmer (JIRA)


[ 
https://issues.apache.org/jira/browse/NETBEANS-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16824147#comment-16824147
 ] 

Scott Palmer commented on NETBEANS-2409:


[~lkishalmi] that installer does not appear to be signed by a trusted source.  
When I attempted to open it Windows Defender warned me:

 
Windows protected your PC
Windows Defender SmartScreen prevented an unrecognized app from starting. 
Running this app might put your PC at risk.
[More info|about:blank#]

> Very Slow  Operations on Windows
> 
>
> Key: NETBEANS-2409
> URL: https://issues.apache.org/jira/browse/NETBEANS-2409
> Project: NetBeans
>  Issue Type: Bug
>Affects Versions: 10.0, 11.0
> Environment: Windows
>Reporter: Laszlo Kishalmi
>Priority: Critical
>  Labels: Performance, Windows, pull-request-available
> Attachments: NB11_autocomplete.nps, NB11_getHint.nps, 
> WinFilesystemSlow.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> What is the best course of action for reporting slowness?  I can’t share my 
> project.
> I’m not certain how to give step-by-step instructions when the problem is 
> basically one step in most cases.  E.g. invoke auto-complete - nothing 
> happens for several seconds.  Invoke rename - dialog doesn’t appear for 
> several seconds.  Find usages - extremely slow > 5 second delay on a private 
> member of a class less than 100 lines.
> In general it seems NB 11 is noticeably slower than NB 8.2. Not good 
> considering slowness was already my #1 complaint about NB 8.2.  I have so far 
> found the benefits of NB outweigh the fact that it is much slower than other 
> IDEs for the same operations, but the slowness of NB 11 is tipping the scale. 
>  I don’t want to switch IDEs, pease don’t interpret this as some sort of 
> threat to do so. I would like to help find the issues in NB.  But I don’t 
> have the bandwidth to debug NB and not being about to share my project makes 
> it difficult to provide helpful reports :-(
> Are others seeing the slowness?
> Find usages, renames, call-hierarchy, auto-complete… things I use all the 
> time, I often have to wait 5 to 10 seconds for a response from the IDE, 
> sometimes more.
> I’ve already deleted user dir and cache and restarted. 
> I’m using Gradle-based Java projects, running NB 11.0 with JDK 8u202.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
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