[jira] [Commented] (NETBEANS-6179) Open Project dialog can take over 30 seconds to appear on Windows.
[ 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.
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
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
[ 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
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
[ 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
[
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
[
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
[
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
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
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
[ 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
[
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
[
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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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
[ 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
[
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
[
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
[
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
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
[
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
[
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
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
[
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
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.
[ 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.
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
[ 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
[ 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
[ 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
[ 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
[
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
[ 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
[ 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
[ 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
[ 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
