[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=16879754#comment-16879754 ] Laszlo Kishalmi commented on NETBEANS-2417: --- [~louhy] As of the anti-aliasing issue. If you comare the dark elephant over light background, the Elephant legs are quite good 2px wide, on the brlu over dark backgroung the elephant legs are just some spikes, making the whole figure like a splash of an ink. > 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, > 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, > nb1.png, nb2.png, nbIcons.png > > Time Spent: 1h 20m > 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 (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] [Updated] (NETBEANS-2792) Gradle EE Run output tab remains in running state (bold title) after deployment
[ https://issues.apache.org/jira/browse/NETBEANS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated NETBEANS-2792: - Labels: pull-request-available (was: ) > Gradle EE Run output tab remains in running state (bold title) after > deployment > --- > > Key: NETBEANS-2792 > URL: https://issues.apache.org/jira/browse/NETBEANS-2792 > Project: NetBeans > Issue Type: Bug > Components: projects - Gradle Java EE >Affects Versions: 11.1 > Environment: Product Version: Apache NetBeans IDE 11.1 > Updates: Updates available > Java: 1.8.0_202; OpenJDK 64-Bit Server VM 25.202-b08 > Runtime: OpenJDK Runtime Environment 1.8.0_202-b08 > System: Windows 10 version 10.0 running on amd64; Cp1252; en_IE (nb) > User directory: C:\Users\falappa\AppData\Roaming\NetBeans\11.1 > Cache directory: C:\Users\falappa\AppData\Local\NetBeans\Cache\11.1 >Reporter: Alessandro Falappa >Assignee: Laszlo Kishalmi >Priority: Minor > Labels: pull-request-available > > Steps > # Create a Gradle Web application project > # Run project (F6) > _Expected_: after launching the application server of the project (if not > running already) and deploying the project WAR artifact the output tab should > stop (normal title) > _Observed_: the application server is launched (if not running already) and > the WAR artifact of the project is deployed but the output tab remains in > running state (bold title) -- 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-2797) Python project run inside NB raising exception while not in command line
[
https://issues.apache.org/jira/browse/NETBEANS-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Laszlo Kishalmi resolved NETBEANS-2797.
---
Resolution: Invalid
Well,
First, the python{color:#33} plugins has not yet in the hands of Apache
NetBeans it will be donated later down the road.{color}
{color:#33}Second, There could be differences with your command line
environment and the environment provided by NetBeans. Make sure that either set
the environments the same, or prepare you application to accommodate to these
differences. If you really think that it is an IDE issue then Analyze further
what the issue really is and file a specific bug or implementation
request.{color}
{color:#33}Also this issue might block your personal work with the IDE, but
surely does not affect those who are working with Java, Java EE, HTML 5 and
PHP. So this issue might be a major, but certainly not a blocker and not even
critical.{color}
> Python project run inside NB raising exception while not in command line
>
>
> Key: NETBEANS-2797
> URL: https://issues.apache.org/jira/browse/NETBEANS-2797
> Project: NetBeans
> Issue Type: Bug
>Affects Versions: 8.2, 11.0
> Environment: Windows, NB11.0, NB8.2
>Reporter: Gururaj
>Priority: Blocker
> Labels: NB11, NB8.2, Python3
>
> If I run a python script, exception is occurring only in NB. If I execute the
> same script with same python interpreter on command line, no exception is
> raised.
> Created sample project "sample_1" with a python test source file. After
> running the project NB output window showing below error:
> {code:java}
> Traceback (most recent call last):
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 2320, in read_nonblocking
> s = self.readConsoleToCursor()
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 2226, in readConsoleToCursor
> if not self.__consout:
> AttributeError: 'Wtty' object has no attribute '_Wtty__consout'
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 1414, in expect_loop
> c = self.read_nonblocking(self.maxread, timeout)
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 1790, in read_nonblocking
> s = self.wtty.read_nonblocking(timeout, size)
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 2341, in read_nonblocking
> raise EOF('End Of File (EOF) in Wtty.read_nonblocking().')
> wexpect.EOF: End Of File (EOF) in Wtty.read_nonblocking().
> During handling of the above exception, another exception occurred:
> Traceback (most recent call last):
> File
> "C:\Users\Srinivag\Documents\NetBeansProjects\sample_1\src\wexpect_test.py",
> line 21, in
> main()
> File
> "C:\Users\Srinivag\Documents\NetBeansProjects\sample_1\src\wexpect_test.py",
> line 16, in main
> child.expect('Enter your user-id/password and clearance level:')
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 1347, in expect
> return self.expect_list(compiled_pattern_list, timeout, searchwindowsize)
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 1361, in expect_list
> return self.expect_loop(searcher_re(pattern_list), timeout, searchwindowsize)
> File
> "C:\Users\Srinivag\AppData\Local\Programs\Python\Python37\lib\site-packages\wexpect.py",
> line 1432, in expect_loop
> raise EOF (str(e) + '\n' + str(self))
> wexpect.EOF: End Of File (EOF) in Wtty.read_nonblocking().
>
> version: 0.0.1.unkown0 ($Revision: 399 $)
> command: C:\WINDOWS\system32\telnet.EXE
> args: ['C:\\WINDOWS\\system32\\telnet.EXE', '10.61.252.10']
> searcher: searcher_re:
> 0: re.compile("Enter your user-id/password and clearance level:")
> buffer (last 100 chars):
> before (last 100 chars):
> after:
> match: None
> match_index: None
> exitstatus: None
> flag_eof: False
> pid: 2460
> child_fd: None
> closed: False
> timeout: 30
> delimiter:
> logfile: None
> logfile_read: <_io.TextIOWrapper name='' mode='w' encoding='cp1252'>
> logfile_send: None
> maxread: 2000
> ignorecase: False
> searchwindowsize: None
> delaybeforesend: 0.05
> delayafterclose: 0.1
> delayafterterminate: 0.1
> {code}
> The code sample_1:wexpect_test.py is as below:
> {code:java}
> # To change this license header, choose License Headers in Project Properties.
> # To change this template file, choose Tools | Templates
> # and open the template in the editor.
>
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879662#comment-16879662
]
Neil C Smith commented on NETBEANS-58:
--
Maybe, but that's not feasibly making it into NB 11.1.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting the following registry key:
>
[netbeans] branch release111 updated: Add Payara Micro dependency in j2ee.kit
This is an automated email from the ASF dual-hosted git repository. neilcsmith pushed a commit to branch release111 in repository https://gitbox.apache.org/repos/asf/netbeans.git The following commit(s) were added to refs/heads/release111 by this push: new d190894 Add Payara Micro dependency in j2ee.kit new ff49da7 Merge pull request #1356 from neilcsmith-net/release111-payara-micro d190894 is described below commit d190894e57891006b3de4e5faf3a272fd6eca5fe Author: Neil C Smith AuthorDate: Fri Jul 5 16:33:42 2019 +0100 Add Payara Micro dependency in j2ee.kit --- enterprise/j2ee.kit/nbproject/project.xml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/enterprise/j2ee.kit/nbproject/project.xml b/enterprise/j2ee.kit/nbproject/project.xml index 31f5911..4f248ab 100644 --- a/enterprise/j2ee.kit/nbproject/project.xml +++ b/enterprise/j2ee.kit/nbproject/project.xml @@ -95,6 +95,12 @@ + org.netbeans.modules.payara.micro + +0-1 + + + org.netbeans.modules.web.kit 1.0 - 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-2809) Navigate to implementation does not work for modular (JPMS) projects
Harald Krake created NETBEANS-2809:
--
Summary: Navigate to implementation does not work for modular
(JPMS) projects
Key: NETBEANS-2809
URL: https://issues.apache.org/jira/browse/NETBEANS-2809
Project: NetBeans
Issue Type: Bug
Components: editor - Navigation
Affects Versions: 11.0
Reporter: Harald Krake
When editing an interface, neither "navigate to implementation" (of the
interface or one of its methods) works nor any gutter icon is shown. If you
remove all module-info files, it works as expected.
Steps to reproduce:
Run the quickstart at [https://bitbucket.org/krake-oss/tentackle/src/master/]
(section "Project Setup" is sufficient, java 11 or newer, maven 3.6.0 or newer):
{{mvn archetype:generate -DarchetypeGroupId=org.tentackle
-DarchetypeArtifactId=tentackle-project-archetype -DarchetypeVersion=11.4.0.0
-DgroupId=com.example -DartifactId=myapp -Dversion=1.0
-Dpackage=com.example.myapp -Dapplication=MyApp}}
{{mvn clean install}}
Open the class MessageDomainImpl.
Click on the "implements" icon next to "public Message create(...)". The
interface MessageDomain will be opened, but there are no gutter icons shown and
you cannot navigate back to the implementations.
Remove all module-info.java files and it works as expected.
--
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-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879618#comment-16879618
]
lbruun commented on NETBEANS-58:
What fixes this issue is NETBEANS-106.
> NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
> ---
>
> Key: NETBEANS-58
> URL: https://issues.apache.org/jira/browse/NETBEANS-58
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Proxy
>Affects Versions: 8.2, 9.0, 11.0
> Environment: Primarily Windows.
>Reporter: phansson
>Priority: Critical
> Attachments: NETBEANS-58-workaround1.diff,
> image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt
>
>
> When any network operation is performed, such as attempting to contact
> NetBeans Update Center, the application (IDE or Platform) may freeze. Users
> will typically experience this on startup. It was reported in old bug tracker
> as [bug 248308|https://netbeans.org/bugzilla/show_bug.cgi?id=248308].
> The problem arises because of the fix JDK folks applied as a consequence of
> the reported [JDK-8032832
> bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. This fix wasn't very
> clever IMO: it puts a lock on the classloader, thus introducing a range of
> other problems, one of them being that NetNeans IDE or NetBeans Platform will
> likely freeze on startup when it attempts a network operation. The fact that
> their fix made things worse (while no doubt fixing the original issue) has
> been reported as
> [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184].
> h3. WHEN DOES IT HAPPEN?
> As the lock is introduced for authentication of type 'Negotiate' it of course
> only happens if there's a network proxy on the path which uses this type of
> authentication. Also known as SPNEGO. This form of authentication is in my
> experience very common in corporate networks, in particular those that base
> themselves on the Microsoft stack. But a person on Oracle's own internal
> network, such as a JDK developer, is most likely not exposed to it. :-)
> There's another condition for it to happen: The JRE runtime must be unable to
> provide 'credentials' (a Kerberos token) to the network proxy on its own.
> SPNEGO is really designed to be seamless and promptless. Support for it was
> added in Java 6. But later on Microsoft tightened the desktop security around
> obtaining the so-called 'session token' and the JDK folks were never able to
> work around this (unlike the makers of Chrome, FF, Opera, etc). Therefore, in
> real-life, SPNEGO in the JRE on Windows is no longer promptless: it will be
> forced to ask the user for credentials, thus negating the idea of SPNEGO. It
> is the prompting which causes the freeze. SPNEGO on Mac OS X and Linux is
> most likely working just fine and the bug will never be experienced.
> h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG?
> This bug in this ticket is characterized by the fact that you'll always be
> able to find the following in your thread dump:
> {noformat}
>at
> sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:)
> - locked (a org.netbeans.ModuleManager$SystemClassLoader)
> {noformat}
> Note that the [Ctrl-Break
> method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html]
> of obtaining a thread dump is favoured over jstack and other methods.
> h3. WHY DOES IT HAPPEN?
> There will be a lock held on the classloader object when the JRE's registered
> Authenticator is invoked. If the Authenticator does work on another thread,
> that other thread has a need for some classloading and the current thread
> needs to wait for the result of that thread, then bum!, there's a deadlock
> between the two threads. This means the lock on the classloader will never be
> released and it will ultimately affect other threads, such as the AWT
> dispatch thread (aka Swing EDT) which will then also lock. Then you have what
> the user experiences as a freeze.
> The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I
> described and will thus be triggering the deadlock. More precisely it will
> happen when NbAuthenticator calls Keyring. Does this mean the NbAuthenticator
> does something wrong? No, of course it doesn't. The real problem is the lock
> on the classloader. It is actually virtually impossible to design an
> Authenticator which doesn't trigger this problem. You cannot predict when
> classloading is needed. In fact it is very likely to be needed when
> application is still not "warm", i.e. during startup.
> h3. WORKAROUNDS
> *#1*
> If on Windows: Setting the following registry key:
>
