[jira] [Commented] (NETBEANS-2644) NB11 gradle plugin can't open buildSrc subproject
[ https://issues.apache.org/jira/browse/NETBEANS-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16857167#comment-16857167 ] Mike commented on NETBEANS-2644: I think I have this same issue. When using NB11 to open a Gradle project with a buildSrc module: the packages under buildSrc/src/main/java don't show up under NetBeans' Projects window which makes them more difficult to edit. > NB11 gradle plugin can't open buildSrc subproject > - > > Key: NETBEANS-2644 > URL: https://issues.apache.org/jira/browse/NETBEANS-2644 > Project: NetBeans > Issue Type: Bug > Components: gradle, projects - Gradle >Affects Versions: 11.0 >Reporter: Shevek >Priority: Major > > Can't find a way to open the buildSrc/ "special" subproject in netbeans 11. > Gone back to netbeans 10 to edit it. > Could be related to the project not building - but I need to edit buildSrc to > fix the build? -- 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] [Created] (NETBEANS-2644) NB11 gradle plugin can't open buildSrc subproject
Shevek created NETBEANS-2644: Summary: NB11 gradle plugin can't open buildSrc subproject Key: NETBEANS-2644 URL: https://issues.apache.org/jira/browse/NETBEANS-2644 Project: NetBeans Issue Type: Bug Components: gradle, projects - Gradle Affects Versions: 11.0 Reporter: Shevek Can't find a way to open the buildSrc/ "special" subproject in netbeans 11. Gone back to netbeans 10 to edit it. Could be related to the project not building - but I need to edit buildSrc to fix the build? -- 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=16856947#comment-16856947
]
Tilman Hausherr commented on NETBEANS-58:
-
NB 11 freezes at startup unless I disconnect the LAN cable, which is what also
happened with NB 8.
> 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
[jira] [Resolved] (NETBEANS-2639) Failed to notify spy org.netbeans.modules.maven.event.NbEventSpy: org/json/simple/JSONObject
[
https://issues.apache.org/jira/browse/NETBEANS-2639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick resolved NETBEANS-2639.
---
Resolution: Fixed
Fix Version/s: Next
> Failed to notify spy org.netbeans.modules.maven.event.NbEventSpy:
> org/json/simple/JSONObject
>
>
> Key: NETBEANS-2639
> URL: https://issues.apache.org/jira/browse/NETBEANS-2639
> Project: NetBeans
> Issue Type: Bug
>Reporter: Jesse Glick
>Assignee: Jesse Glick
>Priority: Critical
> Labels: pull-request-available
> Fix For: Next
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Mentioned in NETBEANS-2481 but does not seem to be filed otherwise. In
> current NB dev versions, when you build any Maven project, all the advanced
> features of the output window are broken and you see repeated warnings
> {code:none}
> Failed to notify spy org.netbeans.modules.maven.event.NbEventSpy:
> org/json/simple/JSONObject
> {code}
--
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
[netbeans] branch master updated: [NETBEANS-2639] Compile mavensrc to Java 7, not 8.
This is an automated email from the ASF dual-hosted git repository. matthiasblaesing pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/netbeans.git The following commit(s) were added to refs/heads/master by this push: new 640e4e6 [NETBEANS-2639] Compile mavensrc to Java 7, not 8. new 6417f2f Merge pull request #1281 from jglick/NbEventSpy-NETBEANS-2639 640e4e6 is described below commit 640e4e64cf7171192faf8bd90821ee65f2cf5ffe Author: Jesse Glick AuthorDate: Tue Jun 4 11:23:57 2019 -0400 [NETBEANS-2639] Compile mavensrc to Java 7, not 8. --- java/maven/build.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/java/maven/build.xml b/java/maven/build.xml index 756f254..d406bde 100644 --- a/java/maven/build.xml +++ b/java/maven/build.xml @@ -30,8 +30,8 @@ - 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-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:all-tabpanel
]
Tilman Hausherr updated NETBEANS-58:
Affects Version/s: 11.0
> 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:
> {{HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\allowtgtsessionkey}}
> to
[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=16856609#comment-16856609
]
Geertjan Wielenga commented on NETBEANS-58:
---
I’m not sure that you need that plugin in 11.0, I believe that functionality is
now included in 11.0 out of the box.
> 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
> 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:
[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=16856596#comment-16856596
]
Tilman Hausherr commented on NETBEANS-58:
-
I just installed netbeans 11 because of NETBEANS-771. When trying to install
proxy selector v2, I get this message:
{quote}
h3. Some plugins require plugin Core to be installed.
The plugin Core is requested in implementation version 201609300101.
The following plugin is affected:
ProxySelector V2
h3. Some plugins require plugin JNA to be installed.
The plugin JNA is requested in implementation version 201609300101.
The following plugin is affected:
ProxySelector V2
{quote}
and I can't "check for updates" because proxy doesn't work. Where can I get
these plugins? A search on the plugin page finds me nothing.
> 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
> 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
[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=16856591#comment-16856591
]
Tilman Hausherr commented on NETBEANS-58:
-
[~phansson] There's a HTML problem in
http://plugins.netbeans.org/plugin/72976/
"You must have Proxy Selector V2 Plugin installed" links to
http://plugins.netbeans.org/plugin/72976/plugin/55258/
it should link to
http://plugins.netbeans.org/plugin/55258/proxyselector-v2
or
http://plugins.netbeans.org/plugin/55258/
> 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
> 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.
[jira] [Commented] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856586#comment-16856586
]
Tilman Hausherr commented on NETBEANS-771:
--
Reluctantly... I installed it (and temporarly disconnected the network cable
because of the problems in NETBEANS-58, I can't even install the plugins from
that issue, because the plugins need to go online to get "plugins core" and
going online freezes netbeans) and it doesn't work:
{noformat}
INFO [org.netbeans.modules.subversion]: Commandline client version:
1.12.0-SlikSvn (SlikSvn/1.12.0)
SEVERE [org.netbeans.modules.subversion]: For input string: "0-SlikSvn"
java.lang.NumberFormatException: For input string: "0-SlikSvn"
at
java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.base/java.lang.Integer.parseInt(Integer.java:652)
at java.base/java.lang.Integer.parseInt(Integer.java:770)
at
org.netbeans.modules.subversion.client.cli.commands.VersionCommand$Version.parse(VersionCommand.java:168)
at
org.netbeans.modules.subversion.client.cli.commands.VersionCommand$Version.parse(VersionCommand.java:146)
at
org.netbeans.modules.subversion.client.cli.commands.VersionCommand.checkForErrors(VersionCommand.java:87)
at
org.netbeans.modules.subversion.client.cli.CommandlineClient.checkSupportedVersion(CommandlineClient.java:132)
at
org.netbeans.modules.subversion.client.SvnClientFactory.checkVersion(SvnClientFactory.java:473)
at
org.netbeans.modules.subversion.client.SvnClientFactory.checkCLIExecutable(SvnClientFactory.java:430)
at
org.netbeans.modules.subversion.client.SvnClientFactory.setupCommandline(SvnClientFactory.java:403)
at
org.netbeans.modules.subversion.client.SvnClientFactory.setup(SvnClientFactory.java:222)
at
org.netbeans.modules.subversion.client.SvnClientFactory.init(SvnClientFactory.java:95)
at
org.netbeans.modules.subversion.client.SvnClientFactory.isClientAvailable(SvnClientFactory.java:240)
at
org.netbeans.modules.subversion.Annotator.checkClientAvailable(Annotator.java:638)
at
org.netbeans.modules.subversion.Annotator.annotateIcon(Annotator.java:506)
{noformat}
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856535#comment-16856535
]
Geertjan Wielenga commented on NETBEANS-771:
Can you try in Apache NetBeans 11.0?
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-2643) configure-on-demand cannot be disabled for custom actions
[ https://issues.apache.org/jira/browse/NETBEANS-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hylke van der Schaaf updated NETBEANS-2643: --- Description: # Select a gradle project in the Projects window # Go to Navigator # Right-click a task and select "Execute Custom..." # Disable "Configure on Demand" # Give a name for "Remember as:" # Click Ok The command now runs as expected, a custom action is created and correctly stored in the projects _gradle.properties_. # Right-click the project in the Projects window # Select "Run Gradle" -> The task made above Gradle is now executed with -_-configure-on-demand_, even though -_-configure-on-demand_ is not part of the _action.custom-X.args_ in the generated _gradle.properties_. was: # Select a gradle project in the Projects window # Go to Navigator # Right-click a task and select "Execute Custom..." # Disable "Configure on Demand" # Give a name for "Remember as:" # Click Ok The command now runs as expected, a custom action is created and correctly stored in the projects _gradle.properties_. # Right-click the project in the Projects window # Select "Run Gradle" -> The task made above Gradle is now executed with _--configure-on-demand_, even though _--configure-on-demand_ is not part of the _action.custom-X.args_ in the generated _gradle.properties_. > configure-on-demand cannot be disabled for custom actions > - > > Key: NETBEANS-2643 > URL: https://issues.apache.org/jira/browse/NETBEANS-2643 > Project: NetBeans > Issue Type: Bug > Components: gradle >Affects Versions: 11.0 >Reporter: Hylke van der Schaaf >Priority: Minor > > # Select a gradle project in the Projects window > # Go to Navigator > # Right-click a task and select "Execute Custom..." > # Disable "Configure on Demand" > # Give a name for "Remember as:" > # Click Ok > The command now runs as expected, a custom action is created and correctly > stored in the projects _gradle.properties_. > # Right-click the project in the Projects window > # Select "Run Gradle" -> The task made above > Gradle is now executed with -_-configure-on-demand_, even though > -_-configure-on-demand_ is not part of the _action.custom-X.args_ in the > generated _gradle.properties_. -- 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] [Created] (NETBEANS-2643) configure-on-demand cannot be disabled for custom actions
Hylke van der Schaaf created NETBEANS-2643: -- Summary: configure-on-demand cannot be disabled for custom actions Key: NETBEANS-2643 URL: https://issues.apache.org/jira/browse/NETBEANS-2643 Project: NetBeans Issue Type: Bug Components: gradle Affects Versions: 11.0 Reporter: Hylke van der Schaaf # Select a gradle project in the Projects window # Go to Navigator # Right-click a task and select "Execute Custom..." # Disable "Configure on Demand" # Give a name for "Remember as:" # Click Ok The command now runs as expected, a custom action is created and correctly stored in the projects _gradle.properties_. # Right-click the project in the Projects window # Select "Run Gradle" -> The task made above Gradle is now executed with _--configure-on-demand_, even though _--configure-on-demand_ is not part of the _action.custom-X.args_ in the generated _gradle.properties_. -- 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] [Comment Edited] (NETBEANS-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856497#comment-16856497
]
Tilman Hausherr edited comment on NETBEANS-771 at 6/5/19 8:42 AM:
--
It's not fixed for 8.2, it happened to me with "8.2 patch 2" after I updated to
1.12.0 from [https://sliksvn.com/download/]
Never change a running system
And per the first comment, this is a bug, not a wish.
was (Author: tilman):
It's not fixed for 8.2, it happened to me with "8.2 patch 2" after I updated to
1.12.0. https://sliksvn.com/download/
Never change a running system
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated NETBEANS-771:
-
Issue Type: Bug (was: Wish)
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Bug
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856497#comment-16856497
]
Tilman Hausherr commented on NETBEANS-771:
--
It's not fixed for 8.2, it happened to me with "8.2 patch 2" after I updated to
1.12.0. https://sliksvn.com/download/
Never change a running system
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Wish
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-771) Support for SubVersion CLI client version 1.10
[
https://issues.apache.org/jira/browse/NETBEANS-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tilman Hausherr updated NETBEANS-771:
-
Affects Version/s: 8.2
> Support for SubVersion CLI client version 1.10
> --
>
> Key: NETBEANS-771
> URL: https://issues.apache.org/jira/browse/NETBEANS-771
> Project: NetBeans
> Issue Type: Wish
> Components: versioncontrol - Subversion
>Affects Versions: 8.2, 9.0
>Reporter: Petr Hadraba
>Priority: Major
> Fix For: 9.0
>
> Attachments: org-netbeans-modules-subversion.jar,
> org-netbeans-modules-subversion.jar
>
>
> SubVersion CLI client version 1.10 does not work in NetBeans 9.0.
> The following message appears in NetBeans log when invoking refresh in
> SubVersion panel:
> {{ INFO [org.netbeans.modules.subversion]: Commandline client version: 1.10.0
> (r1827917)}}
> {{ WARNING [org.netbeans.modules.subversion]: Unsupported svn version. You
> need >= 1.5}}
> {{ WARNING [org.netbeans.modules.subversion.client.SvnClientFactory]:
> executable binary path set to /opt/local/bin yet client not available.}}
> The dialog box appears and says:
>
> {{1. Download and Install Subversion 1.8 or later
> ([http://subversion.apache.org/packages.html]). }}
> \{{ 2. Add it to PATH. }}
> \{{ Test the installation by running 'svn --version' from a command line }}
> \{{ 3. Restart the IDE.}}
> My SubVersion is the latest version:
> {\{ localhost:~ petr$ which svn}}
> \{{ /opt/local/bin/svn}}
> \{{ localhost:~ petr$ svn --version}}
> \{{ svn, version 1.10.0 (r1827917)}}
> \{{ compiled Apr 18 2018, 01:35:41 on x86_64-apple-darwin17.4.0}}
> \{{ }}
> \{{ Copyright (C) 2018 The Apache Software Foundation.}}
> \{{ This software consists of contributions made by many people;}}
> \{{ see the NOTICE file for more information.}}
> {{ Subversion is open source software, see [http://subversion.apache.org/]}}
> \{{ }}
> \{{ The following repository access (RA) modules are available:}}
> \{{ }}
> * {{ra_svn : Module for accessing a repository using the svn network
> protocol.}}{\{ - with Cyrus SASL authentication}}\{{ - handles 'svn'
> scheme}}
> * {{ra_local : Module for accessing a repository on local disk.}}{\{ -
> handles 'file' scheme}}
> * {{ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.}}{\{ - using serf 1.3.9 (compiled with 1.3.8)}}\{{ - handles 'http'
> scheme}}\{{ - handles 'https' scheme}}\{{ }}\{{ The following
> authentication credential caches are available:}}\{{ }}
> * {{Plaintext cache in /Users/petr/.subversion}}
> * {{GPG-Agent}}
> * {{Mac OS X Keychain}}
--
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-2306) Missing resource AmazonJ2EEServerWizardComponent.containerLabel.text
[ https://issues.apache.org/jira/browse/NETBEANS-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pete Whelpton resolved NETBEANS-2306. - Resolution: Fixed Fix Version/s: Next Hopefully fixed by [https://github.com/apache/netbeans/pull/1282] > Missing resource AmazonJ2EEServerWizardComponent.containerLabel.text > > > Key: NETBEANS-2306 > URL: https://issues.apache.org/jira/browse/NETBEANS-2306 > Project: NetBeans > Issue Type: Bug > Components: javaee - Code >Affects Versions: 11.0 >Reporter: Antonio Vieiro >Priority: Major > Labels: pull-request-available > Fix For: Next > > Attachments: netbeans-missing-resource-amazon.txt > > Time Spent: 40m > Remaining Estimate: 0h > > This is for NetBeans 11.0 vc4 running on OpenJDK8 on Linux. > Create a new JavaEE Application (ant based). Then choose to add a server and > select "Amazon Beanstalk" as a target. > An exception is thrown stating a missing resource (attached exception). -- 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] [Assigned] (NETBEANS-2637) IllegalStateException in RequestProcessor after duplicate install attempt of nbjavac Library [1.6] on message request
[ https://issues.apache.org/jira/browse/NETBEANS-2637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Geertjan Wielenga reassigned NETBEANS-2637: --- Assignee: Jan Lahoda > IllegalStateException in RequestProcessor after duplicate install attempt of > nbjavac Library [1.6] on message request > - > > Key: NETBEANS-2637 > URL: https://issues.apache.org/jira/browse/NETBEANS-2637 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.0 >Reporter: Bernard >Assignee: Jan Lahoda >Priority: Blocker > Attachments: messages.log, messages.log, uigestures > > > As part of the discovery of NETBEANS-1824, I gradually built up the IDE > state, adding project after project (14) with some re-starts in between to > get clean log files for inspection. I selected the projects to be simple, and > I verified before with the maven graph viewer that they did not contain the > problematic lombok dependency. In the latest iteration, at a new re-start, > without me doing anything, a NullPointerException occurred (also logged as > message but later disappeared from the message queue) and a message prompt to > install nbjavac Library. I first saved the log to get the NPE and then I > followed the prompt. "The following plugins will be installed: > nbjavac Library [1.6]." This failed with the latest exception which makes > sense because it would have been already installed by the initial > installation and updates. So the 2nd question is what lets the IDE decide to > make this wrong decision? And the 1st question is what is this > NullPointerException that occurs at this iteration where the number of > projects is less than in a different installation of the same version with > the lombok bug present. -- 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-2640) Apache netbeans installation & MySQL connection in ubuntu
[ https://issues.apache.org/jira/browse/NETBEANS-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856462#comment-16856462 ] Geertjan Wielenga commented on NETBEANS-2640: - What is the problem that we should fix, what are the steps to reproduce the problem? Maybe you need a tutorial? Maybe this one: https://netbeans.apache.org/kb/docs/ide/mysql.html > Apache netbeans installation & MySQL connection in ubuntu > - > > Key: NETBEANS-2640 > URL: https://issues.apache.org/jira/browse/NETBEANS-2640 > Project: NetBeans > Issue Type: New Feature >Reporter: Sharma G N >Priority: Blocker > -- 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-2641) Importing netbeans 8.2 java database driven web application projects in apache netbeans
[ https://issues.apache.org/jira/browse/NETBEANS-2641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856461#comment-16856461 ] Geertjan Wielenga commented on NETBEANS-2641: - What is the problem that we should fix, what are the steps to reproduce the problem? You can open any application created in 8.2 into Apache NetBeans. > Importing netbeans 8.2 java database driven web application projects in > apache netbeans > --- > > Key: NETBEANS-2641 > URL: https://issues.apache.org/jira/browse/NETBEANS-2641 > Project: NetBeans > Issue Type: Improvement >Reporter: Sharma G N >Priority: Blocker > -- 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] [Comment Edited] (NETBEANS-2633) Netbeans 11 gradle cannot open projects with dependencies outside the root project
[
https://issues.apache.org/jira/browse/NETBEANS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856431#comment-16856431
]
Rick edited comment on NETBEANS-2633 at 6/5/19 7:27 AM:
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
{color:#8eb021}Customer project 1: (root)
- subproject: customerProject1Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
{color}
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
was (Author: nlrhendr):
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
Customer project 1: (root)
- subproject: customerProject1Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
> Netbeans 11 gradle cannot open projects with dependencies outside the root
> project
> --
>
> Key: NETBEANS-2633
> URL: https://issues.apache.org/jira/browse/NETBEANS-2633
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
>Affects Versions: 11.0
>Reporter: Rick
>Assignee: Laszlo Kishalmi
>Priority: Major
> Attachments: dependencyOutsideRoot.zip,
> image-2019-06-03-14-18-17-417.png, image-2019-06-03-14-18-57-811.png
>
>
> To reproduce, execute the following (after extracting the attached zip file):
> {{cd proj1}}
> {{gradle run}}
> That will output Hello world.
> When opened in netbeans 11, this shows:
> !image-2019-06-03-14-18-17-417.png!
> With the following error
> !image-2019-06-03-14-18-57-811.png!
> So it seems that netbeans thinks proj3 is a root project (which it isn't).
>
> I expect netbeans to open this project without errors. This worked fine in
> netbeans 8.2 with the old gradle plugin.
--
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] [Comment Edited] (NETBEANS-2633) Netbeans 11 gradle cannot open projects with dependencies outside the root project
[
https://issues.apache.org/jira/browse/NETBEANS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856431#comment-16856431
]
Rick edited comment on NETBEANS-2633 at 6/5/19 7:27 AM:
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
{color:#8eb021}Customer project 1: (root)
- subproject: customerProject1Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
{color}
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
was (Author: nlrhendr):
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
{color:#8eb021}Customer project 1: (root)
- subproject: customerProject1Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
{color}
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
> Netbeans 11 gradle cannot open projects with dependencies outside the root
> project
> --
>
> Key: NETBEANS-2633
> URL: https://issues.apache.org/jira/browse/NETBEANS-2633
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
>Affects Versions: 11.0
>Reporter: Rick
>Assignee: Laszlo Kishalmi
>Priority: Major
> Attachments: dependencyOutsideRoot.zip,
> image-2019-06-03-14-18-17-417.png, image-2019-06-03-14-18-57-811.png
>
>
> To reproduce, execute the following (after extracting the attached zip file):
> {{cd proj1}}
> {{gradle run}}
> That will output Hello world.
> When opened in netbeans 11, this shows:
> !image-2019-06-03-14-18-17-417.png!
> With the following error
> !image-2019-06-03-14-18-57-811.png!
> So it seems that netbeans thinks proj3 is a root project (which it isn't).
>
> I expect netbeans to open this project without errors. This worked fine in
> netbeans 8.2 with the old gradle plugin.
--
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] [Comment Edited] (NETBEANS-2633) Netbeans 11 gradle cannot open projects with dependencies outside the root project
[
https://issues.apache.org/jira/browse/NETBEANS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856431#comment-16856431
]
Rick edited comment on NETBEANS-2633 at 6/5/19 7:26 AM:
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
Customer project 1: (root)
- subproject: customerProject1Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific (has the main class that basically
extends an abstract class from proj1)
-- depends on: library:proj1
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
was (Author: nlrhendr):
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
Customer project 1: (root)
- subproject: customerProject1Specific
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
> Netbeans 11 gradle cannot open projects with dependencies outside the root
> project
> --
>
> Key: NETBEANS-2633
> URL: https://issues.apache.org/jira/browse/NETBEANS-2633
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
>Affects Versions: 11.0
>Reporter: Rick
>Assignee: Laszlo Kishalmi
>Priority: Major
> Attachments: dependencyOutsideRoot.zip,
> image-2019-06-03-14-18-17-417.png, image-2019-06-03-14-18-57-811.png
>
>
> To reproduce, execute the following (after extracting the attached zip file):
> {{cd proj1}}
> {{gradle run}}
> That will output Hello world.
> When opened in netbeans 11, this shows:
> !image-2019-06-03-14-18-17-417.png!
> With the following error
> !image-2019-06-03-14-18-57-811.png!
> So it seems that netbeans thinks proj3 is a root project (which it isn't).
>
> I expect netbeans to open this project without errors. This worked fine in
> netbeans 8.2 with the old gradle plugin.
--
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] [Comment Edited] (NETBEANS-2633) Netbeans 11 gradle cannot open projects with dependencies outside the root project
[
https://issues.apache.org/jira/browse/NETBEANS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856431#comment-16856431
]
Rick edited comment on NETBEANS-2633 at 6/5/19 7:24 AM:
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
Customer project 1: (root)
- subproject: customerProject1Specific
-- depends on: library:proj1
Customer project 2: (root)
- subproject: customerProject2Specific
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3: (root)
- subproject: customerProject3Specific
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
was (Author: nlrhendr):
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
Customer project 1:
- subproject: customerProject1Specific
-- depends on: library:proj1
Customer project 2:
- subproject: customerProject2Specific
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3:
- subproject: customerProject3Specific
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
> Netbeans 11 gradle cannot open projects with dependencies outside the root
> project
> --
>
> Key: NETBEANS-2633
> URL: https://issues.apache.org/jira/browse/NETBEANS-2633
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
>Affects Versions: 11.0
>Reporter: Rick
>Assignee: Laszlo Kishalmi
>Priority: Major
> Attachments: dependencyOutsideRoot.zip,
> image-2019-06-03-14-18-17-417.png, image-2019-06-03-14-18-57-811.png
>
>
> To reproduce, execute the following (after extracting the attached zip file):
> {{cd proj1}}
> {{gradle run}}
> That will output Hello world.
> When opened in netbeans 11, this shows:
> !image-2019-06-03-14-18-17-417.png!
> With the following error
> !image-2019-06-03-14-18-57-811.png!
> So it seems that netbeans thinks proj3 is a root project (which it isn't).
>
> I expect netbeans to open this project without errors. This worked fine in
> netbeans 8.2 with the old gradle plugin.
--
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-2633) Netbeans 11 gradle cannot open projects with dependencies outside the root project
[
https://issues.apache.org/jira/browse/NETBEANS-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16856431#comment-16856431
]
Rick commented on NETBEANS-2633:
We need this layout because we have multiple root projects that share a common
library.
Each root project corresponds to a customer project, and those root projects
all have a sub project that contains some customer specific code. For example:
Customer project 1:
- subproject: customerProject1Specific
-- depends on: library:proj1
Customer project 2:
- subproject: customerProject2Specific
-- depends on: library:proj1
-- depends on: library:proj2
Customer project 3:
- subproject: customerProject3Specific
-- depends on: library:proj2
library
- proj1
- proj2 (depends on proj1)
As you can see, it would be impossible to put the library code inside project
1. The library itself is never built separately, so it also does not make sense
for it to have a settings.gradle. I understand that our layout may be a bit
strange, but do you have any suggestions on how this layout could be improved?
> Netbeans 11 gradle cannot open projects with dependencies outside the root
> project
> --
>
> Key: NETBEANS-2633
> URL: https://issues.apache.org/jira/browse/NETBEANS-2633
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Gradle
>Affects Versions: 11.0
>Reporter: Rick
>Assignee: Laszlo Kishalmi
>Priority: Major
> Attachments: dependencyOutsideRoot.zip,
> image-2019-06-03-14-18-17-417.png, image-2019-06-03-14-18-57-811.png
>
>
> To reproduce, execute the following (after extracting the attached zip file):
> {{cd proj1}}
> {{gradle run}}
> That will output Hello world.
> When opened in netbeans 11, this shows:
> !image-2019-06-03-14-18-17-417.png!
> With the following error
> !image-2019-06-03-14-18-57-811.png!
> So it seems that netbeans thinks proj3 is a root project (which it isn't).
>
> I expect netbeans to open this project without errors. This worked fine in
> netbeans 8.2 with the old gradle plugin.
--
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] [Created] (NETBEANS-2640) Apache netbeans installation & MySQL connection in ubuntu
Sharma G N created NETBEANS-2640: Summary: Apache netbeans installation & MySQL connection in ubuntu Key: NETBEANS-2640 URL: https://issues.apache.org/jira/browse/NETBEANS-2640 Project: NetBeans Issue Type: New Feature Reporter: Sharma G N -- 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
