[netbeans-website] branch master updated: Update DevFaqFindLocationInSourcesFromUi.asciidoc
This is an automated email from the ASF dual-hosted git repository. jmborer pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-website.git The following commit(s) were added to refs/heads/master by this push: new 64766d2e7 Update DevFaqFindLocationInSourcesFromUi.asciidoc 64766d2e7 is described below commit 64766d2e7c44f95bb449335ee065eb655ba1751c Author: Jean-Marc Borer AuthorDate: Fri Jul 15 14:07:37 2022 + Update DevFaqFindLocationInSourcesFromUi.asciidoc --- .../src/content/wiki/DevFaqFindLocationInSourcesFromUi.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/netbeans.apache.org/src/content/wiki/DevFaqFindLocationInSourcesFromUi.asciidoc b/netbeans.apache.org/src/content/wiki/DevFaqFindLocationInSourcesFromUi.asciidoc index bf4088f7d..c8add7f32 100644 --- a/netbeans.apache.org/src/content/wiki/DevFaqFindLocationInSourcesFromUi.asciidoc +++ b/netbeans.apache.org/src/content/wiki/DevFaqFindLocationInSourcesFromUi.asciidoc @@ -41,10 +41,10 @@ If you use this switch all strings loaded from `Bundle.properties` files using ` Another handy trick: in a built source tree, run -[source,java] +[source,bash] -ant index-layer-paths +$ ant index-layer-paths to see which module (by code name) contributes each layer file (or folder), - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[netbeans-website] branch master updated: Update DevFaqRemoveStatusBar.asciidoc
This is an automated email from the ASF dual-hosted git repository. jmborer pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-website.git The following commit(s) were added to refs/heads/master by this push: new 6f328b568 Update DevFaqRemoveStatusBar.asciidoc 6f328b568 is described below commit 6f328b56850a8850bcbc5b73aeeb87e845bbda5d Author: Jean-Marc Borer AuthorDate: Fri Jul 15 09:13:07 2022 + Update DevFaqRemoveStatusBar.asciidoc --- netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc b/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc index 0fb54c95e..fff284c15 100644 --- a/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc +++ b/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc @@ -30,7 +30,7 @@ == How do I remove the status bar? -Never be afraid to read the code :-) Looking at org.netbeans.core.windows.view.ui.MainWindow, there is getCustomStatusLine(), and it does this: +Never be afraid to read the code :-) Looking at `org.netbeans.core.windows.view.ui.MainWindow::getCustomStatusLine()`, it does this: [source,java] - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[netbeans-website] branch master updated: Update DevFaqRemoveStatusBar.asciidoc
This is an automated email from the ASF dual-hosted git repository.
jmborer pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans-website.git
The following commit(s) were added to refs/heads/master by this push:
new 341fd96bf Update DevFaqRemoveStatusBar.asciidoc
341fd96bf is described below
commit 341fd96bfe145fc999f3b247f6c065d98650879d
Author: Jean-Marc Borer
AuthorDate: Fri Jul 15 09:12:03 2022 +
Update DevFaqRemoveStatusBar.asciidoc
---
.../content/wiki/DevFaqRemoveStatusBar.asciidoc| 31 --
1 file changed, 17 insertions(+), 14 deletions(-)
diff --git
a/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
b/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
index 3851aa7bd..0fb54c95e 100644
--- a/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
+++ b/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
@@ -18,6 +18,7 @@
//
= DevFaqRemoveStatusBar
+-reviewed: 2022-07-14
:jbake-type: wiki
:jbake-tags: wiki, devfaq, needsreview
:jbake-status: published
@@ -55,12 +56,21 @@ Never be afraid to read the code :-) Looking at
org.netbeans.core.windows.vie
}
-`Constants.CUSTOM_STATUS_LINE_PATH` is defined as
+`Constants.CUSTOM_STATUS_LINE_PATH` is defined as
+
+[source,java]
+
+
System.getProperty("netbeans.winsys.status_line.path");
+
+
+So, have a module which, in its `ModuleInstall` (or as a command-line
parameter in their `myApp.conf`), does
-So, have a module which, in its ModuleInstall (or as a command-line parameter
in their myApp.conf), does
+[source,java]
+
System.setProperty("netbeans.winsys.status_line.path",
"com/foo/com-foo-MyStatusBar.instance");
+
and in its layer file, does something like
@@ -90,18 +100,11 @@ Note you will probably want to provide your own instance
of StatusDisplayer in t
Another option (exception on Mac OS) is to move the status line to the main
menu (it will use the space to the right of the last menu item) -
-netbeans -Dnetbeans.winsys.statusLine.in.menuBar=true
-
-or the equivalent System.setProperty() from a ModuleInstall
-
-== Apache Migration Information
-
-The content in this page was kindly donated by Oracle Corp. to the
-Apache Software Foundation.
+[source,bash]
+
-This page was exported from
link:http://wiki.netbeans.org/DevFaqRemoveStatusBar[http://wiki.netbeans.org/DevFaqRemoveStatusBar]
,
-that was last modified by NetBeans user Geertjan
-on 2010-02-17T20:05:05Z.
+netbeans -Dnetbeans.winsys.statusLine.in.menuBar=true
+
-*NOTE:* This document was automatically converted to the AsciiDoc format on
2018-02-07, and needs to be reviewed.
+or the equivalent `System.setProperty()` from a `ModuleInstall`
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[netbeans-website] branch master updated: Update DevFaqRemoveStatusBar.asciidoc
This is an automated email from the ASF dual-hosted git repository.
jmborer pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/netbeans-website.git
The following commit(s) were added to refs/heads/master by this push:
new f16f0aa6d Update DevFaqRemoveStatusBar.asciidoc
f16f0aa6d is described below
commit f16f0aa6dae313060992d0808427dcb9f2e3c833
Author: Jean-Marc Borer
AuthorDate: Fri Jul 15 09:06:19 2022 +
Update DevFaqRemoveStatusBar.asciidoc
---
.../src/content/wiki/DevFaqRemoveStatusBar.asciidoc| 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git
a/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
b/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
index 322d24d23..3851aa7bd 100644
--- a/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
+++ b/netbeans.apache.org/src/content/wiki/DevFaqRemoveStatusBar.asciidoc
@@ -55,7 +55,7 @@ Never be afraid to read the code :-) Looking at
org.netbeans.core.windows.vie
}
-Constants.CUSTOM_STATUS_LINE_PATH is defined as
+`Constants.CUSTOM_STATUS_LINE_PATH` is defined as
System.getProperty("netbeans.winsys.status_line.path");
So, have a module which, in its ModuleInstall (or as a command-line parameter
in their myApp.conf), does
@@ -64,8 +64,6 @@ System.setProperty("netbeans.winsys.status_line.path",
"com/foo/com-foo-MyStatus
and in its layer file, does something like
-
-
[source,xml]
@@ -74,21 +72,17 @@ and in its layer file, does something like
-
-
and then a class
-package com.foo;
-public class MyStatusBar extends JLabel {
-
[source,java]
+package com.foo;
+public class MyStatusBar extends JLabel {
public Dimension getPreferredSize() { return new Dimension(0,0); }
public Dimension getMaximumSize() { return new Dimension(0,0); } //may not be
necessary
-
-
}
+
and you should get a status bar whose preferred size is to have no size at
all.
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[netbeans-website] branch master updated: Fixed several broken links on DZone
This is an automated email from the ASF dual-hosted git repository. jmborer pushed a commit to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-website.git The following commit(s) were added to refs/heads/master by this push: new 250da0341 Fixed several broken links on DZone 250da0341 is described below commit 250da0341a3ddeeecf0de681067d62cccf6b4c01 Author: Jean-Marc Borer AuthorDate: Thu Jul 14 12:55:37 2022 + Fixed several broken links on DZone --- netbeans.apache.org/src/content/kb/docs/platform/index.asciidoc | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/netbeans.apache.org/src/content/kb/docs/platform/index.asciidoc b/netbeans.apache.org/src/content/kb/docs/platform/index.asciidoc index 00091eed9..298cae6c0 100644 --- a/netbeans.apache.org/src/content/kb/docs/platform/index.asciidoc +++ b/netbeans.apache.org/src/content/kb/docs/platform/index.asciidoc @@ -182,9 +182,9 @@ image::images/five-easy-extend.png[role="left", link="http://www.youtube.com/wat === Miscellaneous * link:http://blogs.oracle.com/geertjan/entry/mavenized_netbeans_platform_runtime_container[Mavenized NetBeans Platform Runtime Container] -* link:http://netbeans.dzone.com/how-create-maven-nb-project-type[Creating Custom Project Types with Maven and the NetBeans Platform] -* link:http://netbeans.dzone.com/nb-how-create-javahelp-mavenized[Creating JavaHelp with Maven and the NetBeans Platform] -* link:http://netbeans.dzone.com/videos/screencast-maven-and-netbeans[Screencast: Maven and the NetBeans Platform] +* link:https://dzone.com/articles/how-create-maven-nb-project-type[Creating Custom Project Types with Maven and the NetBeans Platform] +* link:https://dzone.com/articles/nb-how-create-javahelp-mavenized[Creating JavaHelp with Maven and the NetBeans Platform] +* link:https://dzone.com/articles/video-nbm-maven-archetypes[Screencast: Maven and the NetBeans Platform] == Diagnostics @@ -209,7 +209,7 @@ image::images/five-easy-extend.png[role="left", link="http://www.youtube.com/wat * link:http://blogs.kiyut.com/tonny/2007/10/18/customize-netbeans-platform-splash-screen-and-about-dialog/[Customize the Splash Screen and About Dialog], by Tonny Kohar * link:http://wiki.netbeans.org/wiki/view/AddingMRUList[Create the 'Most Recently Used Files' List], by Tonny Kohar * link:http://wiki.netbeans.org/wiki/view/TranslateNetbeansModule[Translate Your NetBeans Module], by Michel Graciano -* link:http://netbeans.dzone.com/tips/quickstart-guide-language-supp[Quick Start: Creating Language Tools In NetBeans IDE], by Jordi R. Cardona +* link:https://dzone.com/articles/quickstart-guide-language-supp[Quick Start: Creating Language Tools In NetBeans IDE], by Jordi R. Cardona == Reference Material - 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-mavenutils-nbm-maven-plugin] branch master updated: Fix link to mavenized builds FAQs
This is an automated email from the ASF dual-hosted git repository.
jmborer pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/netbeans-mavenutils-nbm-maven-plugin.git
The following commit(s) were added to refs/heads/master by this push:
new 0679de7 Fix link to mavenized builds FAQs
new e8e4e65 Merge pull request #18 from oyarzun/oyarzun-patch-1
0679de7 is described below
commit 0679de769b1d1c6e7879010b6d823138a02363b3
Author: oyarzun
AuthorDate: Tue Sep 7 09:23:19 2021 -0400
Fix link to mavenized builds FAQs
---
src/site/apt/index.apt.vm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/site/apt/index.apt.vm b/src/site/apt/index.apt.vm
index 19827f0..2b812ac 100644
--- a/src/site/apt/index.apt.vm
+++ b/src/site/apt/index.apt.vm
@@ -31,7 +31,7 @@ an autoupdate site content or build and assemble an
application on top of NetBea
Note: The <<>> goal has been moved to it's own
plugin {{{../nb-repository-plugin/index.html}nb-repository-plugin}}.
- Also see:
{{{http://wiki.netbeans.org/NetBeansDeveloperFAQ#Mavenized_Builds}Maven NBM
development FAQs}}
+ Also see:
{{{https://netbeans.apache.org/wiki/DevFaqIndex.asciidoc#_mavenized_builds}Maven
NBM development FAQs}}
Sample <<>> excerpts for creation of a NetBeans module:
-
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-mavenutils-nbm-maven-plugin] branch master updated: Fixed missing Class-Path URL decoding reported in [NETBEANSINFRA-262]
This is an automated email from the ASF dual-hosted git repository.
jmborer pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/netbeans-mavenutils-nbm-maven-plugin.git
The following commit(s) were added to refs/heads/master by this push:
new 54a7ef7 Fixed missing Class-Path URL decoding reported in
[NETBEANSINFRA-262]
54a7ef7 is described below
commit 54a7ef76579bad62f4dce05e326fc93011b14a20
Author: Jean-Marc Borer
AuthorDate: Thu Jan 13 21:05:49 2022 +
Fixed missing Class-Path URL decoding reported in [NETBEANSINFRA-262]
---
.../java/org/apache/netbeans/nbm/CreateClusterAppMojo.java | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/main/java/org/apache/netbeans/nbm/CreateClusterAppMojo.java
b/src/main/java/org/apache/netbeans/nbm/CreateClusterAppMojo.java
index c47e2e8..fdb0ce9 100644
--- a/src/main/java/org/apache/netbeans/nbm/CreateClusterAppMojo.java
+++ b/src/main/java/org/apache/netbeans/nbm/CreateClusterAppMojo.java
@@ -31,8 +31,10 @@ import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
+import java.io.UnsupportedEncodingException;
import java.net.URL;
+import java.net.URLDecoder;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
@@ -371,7 +373,13 @@ public class CreateClusterAppMojo
getModule() ) );
if ( ex.getClasspath().length() >
0 )
{ //MNBMODULE-220
-classPath = ex.getClasspath();
+try
+{
+classPath =
URLDecoder.decode(ex.getClasspath(), "UTF-8");
+} catch
(UnsupportedEncodingException exception)
+{
+throw new
IllegalStateException(exception);
+}
classpathRoot =
fl.getParentFile();
}
}
-
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-mavenutils-nbm-maven-plugin] branch master updated (382210f -> 56ef3d3)
This is an automated email from the ASF dual-hosted git repository. jmborer pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-mavenutils-nbm-maven-plugin.git. from 382210f Merge pull request #9 from javawerks/bug-NETBEANSINFRA-187 new c5930d5 Fix slow copies of module jar files new 81b2da9 Merge branch 'master' into fix_slow_copy new 56ef3d3 Merge pull request #8 from codingfred/fix_slow_copy The 1265 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../netbeans/nbm/CreateNetBeansFileStructure.java | 89 +- 1 file changed, 36 insertions(+), 53 deletions(-) - 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-mavenutils-nbm-maven-plugin] branch master updated (68ca96b -> 382210f)
This is an automated email from the ASF dual-hosted git repository. jmborer pushed a change to branch master in repository https://gitbox.apache.org/repos/asf/netbeans-mavenutils-nbm-maven-plugin.git. from 68ca96b [maven-release-plugin] prepare for next development iteration new 1681948 [NETBEANSINFRA-187] Fixed nbmBuildDir conflict in targets nbm:nbm and nbm:cluster. nbm:cluster was wrongly using the nbmBuildir as output directory instead of clusterBuildDir. new d806657 cluster taget reads the nbms from nbmBuildDir and creates the cluster in clusterBuildDir new aae8671 Improved cluster generation and fixed extra cluster name generation to take branding into account new 9d454d6 Fixed coding style and removed system.err new f5259e1 Coding style refinements new 5537a10 Applied check style modifications. Not everything is fixed new d2176d2 Merge branch 'bug-NETBEANSINFRA-187' of https://github.com/javawerks/netbeans-mavenutils-nbm-maven-plugin into bug-NETBEANSINFRA-187 new 382210f Merge pull request #9 from javawerks/bug-NETBEANSINFRA-187 The 1262 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: pom.xml| 6 +- .../nbmmavenpluginit/ittest/ApplicationTest.java | 27 +- .../org/apache/netbeans/nbm/AbstractNbmMojo.java | 195 +++--- .../org/apache/netbeans/nbm/AdaptNbVersion.java| 5 +- .../java/org/apache/netbeans/nbm/BrandingMojo.java | 79 +-- .../apache/netbeans/nbm/BuildInstallersMojo.java | 96 +-- .../netbeans/nbm/CollectLibrariesNodeVisitor.java | 17 +- .../nbm/CollectModuleLibrariesNodeVisitor.java | 25 +- .../apache/netbeans/nbm/CreateClusterAppMojo.java | 657 +++-- .../org/apache/netbeans/nbm/CreateClusterMojo.java | 63 +- .../org/apache/netbeans/nbm/CreateNbmMojo.java | 117 ++-- .../netbeans/nbm/CreateNetBeansFileStructure.java | 146 ++--- .../apache/netbeans/nbm/CreateStandaloneMojo.java | 13 +- .../apache/netbeans/nbm/CreateUpdateSiteMojo.java | 60 +- .../apache/netbeans/nbm/CreateWebstartAppMojo.java | 205 --- .../netbeans/nbm/NetBeansManifestUpdateMojo.java | 456 +++--- .../org/apache/netbeans/nbm/RunNetBeansMojo.java | 92 +-- .../apache/netbeans/nbm/RunPlatformAppMojo.java| 40 +- src/main/mdo/descriptor.mdo| 8 +- src/main/resources/META-INF/plexus/components.xml | 172 +++--- src/main/resources/branding.jnlp | 24 +- src/main/resources/master.jnlp | 46 +- src/site/site.xml | 38 +- .../apache/netbeans/nbm/AbstractNbmMojoTest.java | 247 .../org/apache/netbeans/nbm/BrandingMojoTest.java | 24 +- .../netbeans/nbm/CreateClusterAppMojoTest.java | 120 ++-- .../nbm/CreateNetBeansFileStructureTest.java | 3 +- .../nbm/NetBeansManifestUpdateMojoTest.java| 76 +-- 28 files changed, 1641 insertions(+), 1416 deletions(-) - 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=17088604#comment-17088604
]
jmborer commented on NETBEANS-58:
-
His Geertjan,
I see indeed that the OpenJDK252 is finally available at Zulu. I'll test it, as
soon as I get back to the office.
Cheers,
Jean-Marc
> 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
> Authentic
[jira] [Comment Edited] (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=16857594#comment-16857594
]
jmborer edited comment on NETBEANS-58 at 6/6/19 12:27 PM:
--
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy in NB is often more closed than open.
IMHO this over protects NB "internals" a little too much. I would have
preferred a policy based on greater openness and trust. This would have
greatly facilitate my life.
was (Author: jmborer):
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy is NB is more often closed than public.
IMHO this over protect NB "internals" a little too much. I would have preferred
a policy based on greater openness and trust. This would have greatly
facilitate my life.
> 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 [
[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=16857594#comment-16857594
]
jmborer commented on NETBEANS-58:
-
@phansson: do you plan to recompile your plugins for NB 11 and release them on
the plugin center?
The 8.2 plugins could have been compatible if they haven't been linked to
implementation version of certain modules. phansson had probably to do it to
get access to classes that are not publicly accessible otherwise.
I ran several times into similar issues with our NB platform based application.
I often regret that the exposure policy is NB is more often closed than public.
IMHO this over protect NB "internals" a little too much. I would have preferred
a policy based on greater openness and trust.
> 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.
[jira] [Comment Edited] (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=16857508#comment-16857508
]
jmborer edited comment on NETBEANS-58 at 6/6/19 10:54 AM:
--
Not sure to understand how the PR is solving the issue. First, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
was (Author: jmborer):
Not sure to understand how the PR is solving the issue. Fist, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
> 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
> de
[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=16857508#comment-16857508
]
jmborer commented on NETBEANS-58:
-
Not sure to understand how the PR is solving the issue. Fist, it seems to
partly solve it by providing SPI for custom Authenticator and secondly I don't
understand in which state the PR currently is.
> 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 vi
[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=16857441#comment-16857441
]
jmborer commented on NETBEANS-58:
-
It seems there is some left over and cleanup to do in the start page, but if we
get back to our freeze issue, I wonder why requests from the start page and
requests to the plugin center(s) are made even thought the start page is not
shown.
The IDE freeze is really occurring for any network request that is made no
matter which module is triggering it.
> 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. Doe
[jira] [Comment Edited] (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=16857437#comment-16857437
]
jmborer edited comment on NETBEANS-58 at 6/6/19 8:48 AM:
-
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
When you navigate the start page it triggers as well GET to
http://netbeans.org/demos.xml
was (Author: jmborer):
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
> 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 wi
[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=16857437#comment-16857437
]
jmborer commented on NETBEANS-58:
-
May be it is a left over when I migrated my preferences from 8.2 to 11.0
I disabled the 8.2 plugins portal as well now.
I opened up again the start page and can observe queries to
[http://www.netbeans.org/news.xml]
Isn't it the RSS feed?
> 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
[jira] [Comment Edited] (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=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:40 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [ http://netbeans-vm.apache.org/uc/11.0/updates.xml.gz?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a_90e7342f-955b-4cc6-8e15-39e4810b37c2|http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz] Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > 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:
[jira] [Comment Edited] (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=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:38 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: http://www.netbeans.org/news.xml [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > 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 longe
[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=16857431#comment-16857431
]
jmborer commented on NETBEANS-58:
-
Hmm. That is a very good question. I don't know if Tilman Hausherr is running
into this issue because of the start page or if it is related to other network
requests.
The start page is just another trigger for network requests.
For example, when I start my IDE where the start page is already disabled
(unchecked "show on startup") and no projects open, NB still triggers network
requests to:
http://www.netbeans.org/news.xml
[http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a]
These request can lead to the deadlock of the IDE.
What is particularly annoying with this issue is its unpredictability. It can
bite you or not. For example our new very faster PCs with SSDs are more likely
(not to say systematically) to run into this issue where my older machine seems
not to be affected. This is pure luck.
> 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
[jira] [Comment Edited] (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=16857390#comment-16857390
]
jmborer edited comment on NETBEANS-58 at 6/6/19 8:11 AM:
-
I confirm that this still happens with NB 11.
As I said before, not the best advertisement for NB when you try to convince
people to adopt it.
When you install NB, it will by default open the welcome "start" page which
triggers network requests.
was (Author: jmborer):
I confirm that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> 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 in
[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=16857390#comment-16857390
]
jmborer commented on NETBEANS-58:
-
I confirme that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> 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 ul
[jira] [Comment Edited] (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=16857390#comment-16857390
]
jmborer edited comment on NETBEANS-58 at 6/6/19 7:58 AM:
-
I confirm that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
was (Author: jmborer):
I confirme that this still happens with NB 11.
I find this really an important issue. When it bites you (my colleagues for
example), it is not the best user experience you can expect from such an
amazing IDE. My colleagues were quite upset and immediately thought to change
their IDE for an alternative. Hopefully this only happens in specific working
environment, but still, not the best promotion for NB...
When you install NB, it will by default open the welcome "start" page which
triggers network requests. I still don't understand why this issue can't be
fixed in NB. If I remember well when I hunted down the issue, it is the
asynchronous request to the Keyring with another thread that deadlock each
other...
> 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.isSupporte
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704489#comment-16704489
]
jmborer edited comment on NETBEANS-635 at 11/30/18 9:53 AM:
Thank you Arnaud. IMHO, it won't be possible to easily fix
TestOutputListenerProvider to properly support both surefire and failsafe as
they are two different plugins with their own report dirs and specific
behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
I have created a Jira entry for that
https://issues.apache.org/jira/browse/NETBEANS-1763
was (Author: jmborer):
Thank you Arnaud. IMHO, it won't be possible to easily fix
TestOutputListenerProvider to properly support both surefire and failsafe as
they are two different plugins with their own report dirs and specific
behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output.txt, surefire-2.18.1-output.txt,
> surefire-2.19.1-.png, surefire-2.19.1-logging-output.txt,
> surefire-2.19.1-output.txt, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output.txt, surefire-2.22.1-output.txt,
> surefire-3.0.0-M3-logging-output.txt, surefire-3.0.0-M3-output.txt,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-1763) Refactor the test output processor to handle both surefire and failsafe plugins
jmborer created NETBEANS-1763: - Summary: Refactor the test output processor to handle both surefire and failsafe plugins Key: NETBEANS-1763 URL: https://issues.apache.org/jira/browse/NETBEANS-1763 Project: NetBeans Issue Type: Improvement Components: projects - Maven Affects Versions: 9.0, 10.0 Reporter: jmborer Currently the Maven test results output processor is mainly focused on handling the Surefire output. The ouput of Failsafe is partly covered. This job is done in a single class called TestOutputListenerProvider. To provide a cleaner and robuster support for both Surefire and Failsafe test results parsing, it becomes necessary to refactor TestOutputListenerProvider into two specialized output processors: one for Surefire and one for Failsafe. -- 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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704489#comment-16704489
]
jmborer edited comment on NETBEANS-635 at 11/30/18 9:44 AM:
Thank you Arnaud. IMHO, it won't be possible to easily fix
TestOutputListenerProvider to properly support both surefire and failsafe as
they are two different plugins with their own report dirs and specific
behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
was (Author: jmborer):
Thank you Arnaud. IMHO, it won't be possible to easily fix
TestOutputListenerProvider to support both surefire and failsafe as they are
two different plugins with their own report dirs and specific behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output.txt, surefire-2.18.1-output.txt,
> surefire-2.19.1-.png, surefire-2.19.1-logging-output.txt,
> surefire-2.19.1-output.txt, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output.txt, surefire-2.22.1-output.txt,
> surefire-3.0.0-M3-logging-output.txt, surefire-3.0.0-M3-output.txt,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704489#comment-16704489
]
jmborer edited comment on NETBEANS-635 at 11/30/18 9:43 AM:
Thank you Arnaud. IMHO, it won't be possible to easily fix
TestOutputListenerProvider to support both surefire and failsafe as they are
two different plugins with their own report dirs and specific behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
was (Author: jmborer):
Thank you Arnaud. IMHO, it won't be possible to fix TestOutputListenerProvider
to support both surefire and failsafe as they are two different plugins with
their own report dirs and specific behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output.txt, surefire-2.18.1-output.txt,
> surefire-2.19.1-.png, surefire-2.19.1-logging-output.txt,
> surefire-2.19.1-output.txt, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output.txt, surefire-2.22.1-output.txt,
> surefire-3.0.0-M3-logging-output.txt, surefire-3.0.0-M3-output.txt,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704489#comment-16704489
]
jmborer commented on NETBEANS-635:
--
Thank you Arnaud. IMHO, it won't be possible to fix TestOutputListenerProvider
to support both surefire and failsafe as they are two different plugins with
their own report dirs and specific behaviors.
A better idea would be to refactor TestOutputListenerProvider into
SurefireOutputListenerProvider and FailsafeOutputListenerProvider that will
respectively process surefire and failsafe outputs.
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output.txt, surefire-2.18.1-output.txt,
> surefire-2.19.1-.png, surefire-2.19.1-logging-output.txt,
> surefire-2.19.1-output.txt, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output.txt, surefire-2.22.1-output.txt,
> surefire-3.0.0-M3-logging-output.txt, surefire-3.0.0-M3-output.txt,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16703062#comment-16703062
]
jmborer edited comment on NETBEANS-635 at 11/29/18 11:40 AM:
-
I agree.
I also had this idea in mind, but did not dare to go to far. I had a rather
conservative approach. If this would be my decision only, I would not check the
version except if this becomes necessary at some point.
I don't know failsafe, do you know if surefire and faisafe generate their
reports in the same directory? If no, then need two separate regular
expressions.
was (Author: jmborer):
I agree.
I also had this idea in mind, but did not dare to go to far. I had a rather
conservative approach. If this would be my decision only, I would not check the
version except if this becomes necessary at some point.
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output.txt, surefire-2.18.1-output.txt,
> surefire-2.19.1-.png, surefire-2.19.1-logging-output.txt,
> surefire-2.19.1-output.txt, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output.txt, surefire-2.22.1-output.txt,
> surefire-3.0.0-M3-logging-output.txt, surefire-3.0.0-M3-output.txt,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-2.19.1-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: surefire-3.0.0-M3-output.txt
surefire-3.0.0-M3-logging-output.txt
surefire-2.22.1-output.txt
surefire-2.22.1-logging-output.txt
surefire-2.19.1-output.txt
surefire-2.19.1-logging-output.txt
surefire-2.18.1-output.txt
surefire-2.18.1-logging-output.txt
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output.txt, surefire-2.18.1-output.txt,
> surefire-2.19.1-.png, surefire-2.19.1-logging-output.txt,
> surefire-2.19.1-output.txt, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output.txt, surefire-2.22.1-output.txt,
> surefire-3.0.0-M3-logging-output.txt, surefire-3.0.0-M3-output.txt,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-2.22.1-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-3.0.0-M3-logging-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-2.19.1-logging-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-2.18.1-logging-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-2.19.1-logging-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-3.0.0-M3-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: (was: surefire-2.18.1-output)
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: surefire-3.0.0-M3-logging-output
surefire-2.22.1-output
surefire-2.22.1-logging-output
surefire-2.19.1-output
surefire-2.19.1-logging-output
surefire-2.18.1-output
surefire-2.18.1-logging-output
surefire-3.0.0-M3-output
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Labels: pull-request-available
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.18.1-logging-output, surefire-2.18.1-output, surefire-2.19.1-.png,
> surefire-2.19.1-logging-output, surefire-2.19.1-output, surefire-2.22.1-.png,
> surefire-2.22.1-logging-output, surefire-2.22.1-output,
> surefire-3.0.0-M3-logging-output, surefire-3.0.0-M3-output,
> target-2.18.1.zip, target-2.19.1.zip, target-2.22.1.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:09 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{{^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$}}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{{.*---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$}}
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUni
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:10 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{{^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$}}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{{.*---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$}}
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce additional output and is not what most users would expect (a
clutted or too detailed report):
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:09 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{{^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$}}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{code:java}
{code}
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.${code}
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:01 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$
should be replaced by:
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Pr
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:07 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{code:java}
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*${code}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{code:java}
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.${code}
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:02 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{noformat}
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*${noformat}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 12:02 PM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Pr
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 11:59 AM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{noformat}
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*${noformat}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 11:58 AM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Pr
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 11:58 AM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{noformat}
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*$
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{noformat}
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.$
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.
[jira] [Comment Edited] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer edited comment on NETBEANS-635 at 11/28/18 11:57 AM:
-
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by:
{noformat}
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*${noformat}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{noformat}
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.${noformat}
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.
[jira] [Commented] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701771#comment-16701771
]
jmborer commented on NETBEANS-635:
--
There are several issues to properly handle the surefire plugin output
Since Surefire 2.19 the line which specifies the output directory (see below)
is no longer printed:
{noformat}
Surefire report directory: {noformat}
There is a fallback method to find the reports by trying to parse a line like:
{noformat}
--- maven-surefire-plugin:2.18.1:test (default-test) @ mavenproject3 ---
{noformat}
which then uses the test name to find the report file name. However the
regular expression is flawed: it will skip the line above because of the third
digit:
{noformat}
^---\smaven-surefire-plugin:\d+\.\d+:test\s.*$ {noformat}
should be replaced by
{noformat}
^---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.*${noformat}
However this fallback method won't work either, because depending on the Maven
settings, the output will be prefixed with the log level (for example [INFO])
that will break the matching. It must improved further to take this into
account:
{noformat}
^.---\smaven-surefire-plugin:\d+(?:.\d+)+:test\s.${noformat}
By looking into the surefire code, it is possible to have the "Surefire report
directory" line appear again by using the "-e" argument for Maven. However,
this will produce more output and is not what most users would expect:
{noformat}
C:\Users\borerjc\NetBeansProjects\mavenproject3>mvn -e install
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO]
[INFO] < ch.skyguide.crystal:mavenproject3 >-
[INFO] Building mavenproject3 6.0-SNAPSHOT
[INFO] ---[ jar ]
[INFO]
[INFO] — maven-resources-plugin:2.6:resources (default-resources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\main\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:compile (default-compile) @ mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-resources-plugin:2.6:testResources (default-testResources) @
mavenproject3 —
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
C:\Users\borerjc\NetBeansProjects\mavenproject3\src\test\resources
[INFO]
[INFO] — maven-compiler-plugin:3.1:testCompile (default-testCompile) @
mavenproject3 —
[INFO] Nothing to compile - all classes are up to date
[INFO]
[INFO] — maven-surefire-plugin:2.22.1:test (default-test) @ mavenproject3 —
[INFO] Surefire report directory:
C:\Users\borerjc\NetBeansProjects\mavenproject3\target\surefire-reports
[INFO]
[INFO] ---
[INFO] T E S T S
[INFO] ---
[INFO] Running ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.042
s <<< FAILURE! - in ch.skyguide.crystal.mavenproject3.TestTest
[ERROR] testSomeMethod(ch.skyguide.crystal.mavenproject3.TestTest) Time
elapsed: 0.006 s <<< FAILURE!
java.lang.AssertionError: dummy message
at org.junit.Assert.fail(Assert.java:88)
at ch.skyguide.crystal.mavenproject3.TestTest.testSomeMethod(TestTest.java:22)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at
org.apache.maven.surefire.junit4.JUnit4Pr
[jira] [Updated] (NETBEANS-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: target-2.22.1.zip
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: target-2.18.1.zip
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: target-2.19.1.zip
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png, target-2.18.1.zip,
> target-2.19.1.zip, target-2.22.1.zip
>
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: surefire-2.19.1-.png
surefire-2.18.1-.png
surefire-2.22.1-.png
> Surefire 2.19.1 (and later) stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Attachments: mavenproject3.zip, surefire-2.18.1-.png,
> surefire-2.19.1-.png, surefire-2.22.1-.png
>
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699276#comment-16699276
]
jmborer commented on NETBEANS-635:
--
I added a sample project to show the issue. It won't work neither with NB 8.2
nor with 9.0
> Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Attachments: mavenproject3.zip
>
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Attachment: mavenproject3.zip
> Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
> Attachments: mavenproject3.zip
>
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-1749) about_dark_nb.png is not PNG
jmborer created NETBEANS-1749: - Summary: about_dark_nb.png is not PNG Key: NETBEANS-1749 URL: https://issues.apache.org/jira/browse/NETBEANS-1749 Project: NetBeans Issue Type: Bug Components: core Affects Versions: 9.0 Reporter: jmborer Apparently, when you use a dark LaF the about_dark_nb.png resources seems to be wrong: INFO [org.openide.util.ImageUtilities]: Image org/netbeans/core/startup/about_dark_nb.png is not PNG javax.imageio.IIOException: Bad PNG signature! at com.sun.imageio.plugins.png.PNGImageReader.readHeader(PNGImageReader.java:242) Caused: javax.imageio.IIOException: I/O error reading PNG header! at com.sun.imageio.plugins.png.PNGImageReader.readHeader(PNGImageReader.java:315) at com.sun.imageio.plugins.png.PNGImageReader.readMetadata(PNGImageReader.java:654) at com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1256) at com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1614) [catch] at org.openide.util.ImageUtilities.getIcon(ImageUtilities.java:545) at org.openide.util.ImageUtilities.getIcon(ImageUtilities.java:458) at org.openide.util.ImageUtilities.loadImage(ImageUtilities.java:143) at org.netbeans.core.startup.Splash.loadContent(Splash.java:210) at org.netbeans.core.ui.ProductInformationPanel.(ProductInformationPanel.java:123) at org.netbeans.core.actions.AboutAction.performAction(AboutAction.java:48) at org.openide.util.actions.CallableSystemAction$1.run(CallableSystemAction.java:105) at org.openide.util.actions.ActionInvoker$1.run(ActionInvoker.java:70) at org.openide.util.actions.ActionInvoker.doPerformAction(ActionInvoker.java:91) at org.openide.util.actions.ActionInvoker.invokeAction(ActionInvoker.java:74) at org.openide.util.actions.CallableSystemAction.actionPerformed(CallableSystemAction.java:102) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2348) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.AbstractButton.doClick(AbstractButton.java:376) at javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:842) at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:886) at java.awt.Component.processMouseEvent(Component.java:6539) at javax.swing.JComponent.processMouseEvent(JComponent.java:3324) at java.awt.Component.processEvent(Component.java:6304) at java.awt.Container.processEvent(Container.java:2239) at java.awt.Component.dispatchEventImpl(Component.java:4889) at java.awt.Container.dispatchEventImpl(Container.java:2297) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4904) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4535) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4476) at java.awt.Container.dispatchEventImpl(Container.java:2283) at java.awt.Window.dispatchEventImpl(Window.java:2746) at java.awt.Component.dispatchEvent(Component.java:4711) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:760) at java.awt.EventQueue.access$500(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:709) at java.awt.EventQueue$3.run(EventQueue.java:703) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:84) at java.awt.EventQueue$4.run(EventQueue.java:733) at java.awt.EventQueue$4.run(EventQueue.java:731) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) at java.awt.EventQueue.dispatchEvent(EventQueue.java:730) at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) -- 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
[jira] [Commented] (NETBEANS-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698859#comment-16698859
]
jmborer commented on NETBEANS-635:
--
Tried also with 2.20.x, 2.21.x, 2.22.x. Doesn't work either.
> Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-635) Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
[
https://issues.apache.org/jira/browse/NETBEANS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jmborer updated NETBEANS-635:
-
Affects Version/s: 9.0
> Surefire 2.19.1 stacktrace hyperlinks don't work with Maven
> ---
>
> Key: NETBEANS-635
> URL: https://issues.apache.org/jira/browse/NETBEANS-635
> Project: NetBeans
> Issue Type: Bug
> Components: projects - Maven
>Affects Versions: 8.2, 9.0
>Reporter: jmborer
>Priority: Major
>
> When running tests with surefire 2.19.1, to see the stacktrace, make sure the
> plugin is configured as following:
> {code:java}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> false
>
> {code}
> Then you will see the stacktraces in the output. Even though they are
> recognized as being hyperlinks, when you click on them, nothing happens and
> in the status bar of Netbeans it says that the source file cannot be found.
> This works perfectly with surefire 2.18.1. Something changed between these
> versions.
> Related topics:
> [1] [https://netbeans.org/bugzilla/show_bug.cgi?id=257563]
> [2] [https://netbeans.org/bugzilla/show_bug.cgi?id=222587]
> [3] [https://netbeans.org/bugzilla/show_bug.cgi?id=262207]
>
>
--
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-1730) Make module org.netbeans.api:org-netbeans-swing-plaf package org.netbeans.swing.plaf.util public
[ https://issues.apache.org/jira/browse/NETBEANS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696103#comment-16696103 ] jmborer edited comment on NETBEANS-1730 at 11/22/18 4:39 PM: - Another option is to use the implementation version anyway, by building the sources with the same build number as the official NB 9.0 release. So my plugin can use the "private" classes, but the plugin will only work with a given build even though it could work with other versions of netbeans :( I just need to run the build with -Dbuildnumber=x was (Author: jmborer): Another option is to use the implementation version anyway, by building the sources with the same build number as the official NB 9.0 release. So my plugin can use the "private" classes, but the plugin will only work with a given build even though it could work with other versions of netbeans :( > Make module org.netbeans.api:org-netbeans-swing-plaf package > org.netbeans.swing.plaf.util public > > > Key: NETBEANS-1730 > URL: https://issues.apache.org/jira/browse/NETBEANS-1730 > Project: NetBeans > Issue Type: Wish > Components: platform - Other >Affects Versions: 9.0 >Reporter: jmborer >Priority: Major > Fix For: Next > > > It would be really usefull to expose publicly package > org.netbeans.swing.plaf.util of module > org.netbeans.api:org-netbeans-swing-plaf for LaF module designers. > For example classes: org.netbeans.swing.plaf.util.RelativeColor, > org.netbeans.swing.plaf.util.GuaranteedValue, > org.netbeans.swing.plaf.util.UIBootstrapValue$Lazy, > org.netbeans.swing.plaf.util.UIBootstrapValue are necessary for Darcula > support. > There is a workaround to set a dependency on the implementation version of > the module to get access to private classes, but this is not resilient > solutions. > There is another workaround where you copy the source of required classes > into the project, but this is not very nice too and can lead to potential > conflicts and a lot of classes to copy. -- 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-1730) Make module org.netbeans.api:org-netbeans-swing-plaf package org.netbeans.swing.plaf.util public
[ https://issues.apache.org/jira/browse/NETBEANS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696103#comment-16696103 ] jmborer commented on NETBEANS-1730: --- Another option is to use the implementation version anyway, by building the sources with the same build number as the official NB 9.0 release. So my plugin can use the "private" classes, but the plugin will only work with a given build even though it could work with other versions of netbeans :( > Make module org.netbeans.api:org-netbeans-swing-plaf package > org.netbeans.swing.plaf.util public > > > Key: NETBEANS-1730 > URL: https://issues.apache.org/jira/browse/NETBEANS-1730 > Project: NetBeans > Issue Type: Wish > Components: platform - Other >Affects Versions: 9.0 >Reporter: jmborer >Priority: Major > Fix For: Next > > > It would be really usefull to expose publicly package > org.netbeans.swing.plaf.util of module > org.netbeans.api:org-netbeans-swing-plaf for LaF module designers. > For example classes: org.netbeans.swing.plaf.util.RelativeColor, > org.netbeans.swing.plaf.util.GuaranteedValue, > org.netbeans.swing.plaf.util.UIBootstrapValue$Lazy, > org.netbeans.swing.plaf.util.UIBootstrapValue are necessary for Darcula > support. > There is a workaround to set a dependency on the implementation version of > the module to get access to private classes, but this is not resilient > solutions. > There is another workaround where you copy the source of required classes > into the project, but this is not very nice too and can lead to potential > conflicts and a lot of classes to copy. -- 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-1730) Make module org.netbeans.api:org-netbeans-swing-plaf package org.netbeans.swing.plaf.util public
jmborer created NETBEANS-1730: - Summary: Make module org.netbeans.api:org-netbeans-swing-plaf package org.netbeans.swing.plaf.util public Key: NETBEANS-1730 URL: https://issues.apache.org/jira/browse/NETBEANS-1730 Project: NetBeans Issue Type: Wish Components: platform - Other Affects Versions: 9.0 Reporter: jmborer Fix For: Next It would be really usefull to expose publicly package org.netbeans.swing.plaf.util of module org.netbeans.api:org-netbeans-swing-plaf for LaF module designers. For example classes: org.netbeans.swing.plaf.util.RelativeColor, org.netbeans.swing.plaf.util.GuaranteedValue, org.netbeans.swing.plaf.util.UIBootstrapValue$Lazy, org.netbeans.swing.plaf.util.UIBootstrapValue are necessary for Darcula support. There is a workaround to set a dependency on the implementation version of the module to get access to private classes, but this is not resilient solutions. There is another workaround where you copy the source of required classes into the project, but this is not very nice too and can lead to potential conflicts and a lot of classes to copy. -- 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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted
[ https://issues.apache.org/jira/browse/NETBEANS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16694588#comment-16694588 ] jmborer commented on NETBEANS-467: -- Ok guys, now I am confused: which of the github repo below is supposed to be the reference implementation: [https://github.com/mojohaus/nbm-maven-plugin|https://github.com/apache/incubator-netbeans-mavenutils/] [https://github.com/apache/incubator-netbeans-mavenutils/] Help will be appreciated. > maven artifacts for Apache NetBeans Platform need to be created and hosted > --- > > Key: NETBEANS-467 > URL: https://issues.apache.org/jira/browse/NETBEANS-467 > Project: NetBeans > Issue Type: Task > Components: website >Affects Versions: 9.0 >Reporter: Eric Barboni >Priority: Critical > Labels: NETBEANS-9 > > Hi (hope I did not miss mails on this topic), > During test on maven NetCAT, testers are told to create and generate > mavenized NetBeans Platform Module and Suite. > Maven archetype for Netbeans platform module [1] are linked to artefacts > stored in [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot > versions from [3] > Artefacts are generated from Oracle NetBeans sources at the moment, RELEASE* > artefact were built from a specific build, SNAPSHOT artefact are refreshed > every day with no history (I suppose for space reason). > > It would be nice to recreate a workflow to regenerate maven artefacts for > the Apache NetBeans Platform from Apache NetBeans sources. > > [1][https://github.com/mojohaus/nbm-archetype/] > [2][https://bits.netbeans.org/nexus] > [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/] > > > -- 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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted
[ https://issues.apache.org/jira/browse/NETBEANS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503326#comment-16503326 ] jmborer commented on NETBEANS-467: -- Thanks. This is helpful. > maven artifacts for Apache NetBeans Platform need to be created and hosted > --- > > Key: NETBEANS-467 > URL: https://issues.apache.org/jira/browse/NETBEANS-467 > Project: NetBeans > Issue Type: Task > Components: website >Affects Versions: 9.0 >Reporter: Eric Barboni >Priority: Critical > Labels: NETBEANS-9 > > Hi (hope I did not miss mails on this topic), > During test on maven NetCAT, testers are told to create and generate > mavenized NetBeans Platform Module and Suite. > Maven archetype for Netbeans platform module [1] are linked to artefacts > stored in [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot > versions from [3] > Artefacts are generated from Oracle NetBeans sources at the moment, RELEASE* > artefact were built from a specific build, SNAPSHOT artefact are refreshed > every day with no history (I suppose for space reason). > > It would be nice to recreate a workflow to regenerate maven artefacts for > the Apache NetBeans Platform from Apache NetBeans sources. > > [1][https://github.com/mojohaus/nbm-archetype/] > [2][https://bits.netbeans.org/nexus] > [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/] > > > -- 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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted
[ https://issues.apache.org/jira/browse/NETBEANS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501726#comment-16501726 ] jmborer commented on NETBEANS-467: -- Ok ok. Not aware about all the stuff around the donation/migration. So it is a no brainer. Any idea when Oracle will actually transfer netbeans.org to the Apache Foundation, since it seems the root of the issue? > maven artifacts for Apache NetBeans Platform need to be created and hosted > --- > > Key: NETBEANS-467 > URL: https://issues.apache.org/jira/browse/NETBEANS-467 > Project: NetBeans > Issue Type: Task > Components: website >Affects Versions: 9.0 >Reporter: Eric Barboni >Priority: Critical > Labels: NETBEANS-9 > > Hi (hope I did not miss mails on this topic), > During test on maven NetCAT, testers are told to create and generate > mavenized NetBeans Platform Module and Suite. > Maven archetype for Netbeans platform module [1] are linked to artefacts > stored in [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot > versions from [3] > Artefacts are generated from Oracle NetBeans sources at the moment, RELEASE* > artefact were built from a specific build, SNAPSHOT artefact are refreshed > every day with no history (I suppose for space reason). > > It would be nice to recreate a workflow to regenerate maven artefacts for > the Apache NetBeans Platform from Apache NetBeans sources. > > [1][https://github.com/mojohaus/nbm-archetype/] > [2][https://bits.netbeans.org/nexus] > [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/] > > > -- 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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted
[ https://issues.apache.org/jira/browse/NETBEANS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501712#comment-16501712 ] jmborer commented on NETBEANS-467: -- Well it depends. If Oracle committed or agreed to donate netbeans.org to the community, then it is almost a matter of time. If not, then there will be an issue anyway and then the real question becomes: shall netbeans still remain netbeans or get a new birth name hosted at apache: netbeans.apache.org... > maven artifacts for Apache NetBeans Platform need to be created and hosted > --- > > Key: NETBEANS-467 > URL: https://issues.apache.org/jira/browse/NETBEANS-467 > Project: NetBeans > Issue Type: Task > Components: website >Affects Versions: 9.0 >Reporter: Eric Barboni >Priority: Critical > Labels: NETBEANS-9 > > Hi (hope I did not miss mails on this topic), > During test on maven NetCAT, testers are told to create and generate > mavenized NetBeans Platform Module and Suite. > Maven archetype for Netbeans platform module [1] are linked to artefacts > stored in [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot > versions from [3] > Artefacts are generated from Oracle NetBeans sources at the moment, RELEASE* > artefact were built from a specific build, SNAPSHOT artefact are refreshed > every day with no history (I suppose for space reason). > > It would be nice to recreate a workflow to regenerate maven artefacts for > the Apache NetBeans Platform from Apache NetBeans sources. > > [1][https://github.com/mojohaus/nbm-archetype/] > [2][https://bits.netbeans.org/nexus] > [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/] > > > -- 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-467) maven artifacts for Apache NetBeans Platform need to be created and hosted
[ https://issues.apache.org/jira/browse/NETBEANS-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501668#comment-16501668 ] jmborer commented on NETBEANS-467: -- I don't want NB 9.0 to be blocked, but why isn't it possible to rebuild the artifacts from the source code (I don't care about the C++ modules to build my platform based application). However as long as no NB 9.0 artifacts can be used, I won't be able to migrate to Java 9 and NB 9.0 which might become a big issue next year. Be careful, if this action is postponed for too long, this will not help acceptance and adoption for NB platform in the future... > maven artifacts for Apache NetBeans Platform need to be created and hosted > --- > > Key: NETBEANS-467 > URL: https://issues.apache.org/jira/browse/NETBEANS-467 > Project: NetBeans > Issue Type: Task > Components: website >Affects Versions: 9.0 >Reporter: Eric Barboni >Priority: Critical > Labels: NETBEANS-9 > > Hi (hope I did not miss mails on this topic), > During test on maven NetCAT, testers are told to create and generate > mavenized NetBeans Platform Module and Suite. > Maven archetype for Netbeans platform module [1] are linked to artefacts > stored in [2] (RELEASE 6 to 8.2) and it is also possible to use snapshot > versions from [3] > Artefacts are generated from Oracle NetBeans sources at the moment, RELEASE* > artefact were built from a specific build, SNAPSHOT artefact are refreshed > every day with no history (I suppose for space reason). > > It would be nice to recreate a workflow to regenerate maven artefacts for > the Apache NetBeans Platform from Apache NetBeans sources. > > [1][https://github.com/mojohaus/nbm-archetype/] > [2][https://bits.netbeans.org/nexus] > [3][https://bits.netbeans.org/dev/maven-snapshot/|http://bits.netbeans.org/dev/maven-snapshot/] > > > -- 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=16452044#comment-16452044
]
jmborer commented on NETBEANS-58:
-
Done in https://github.com/apache/incubator-netbeans/pull/2
> 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 fa
[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=16451834#comment-16451834
]
jmborer commented on NETBEANS-58:
-
[~GeertjanWielenga] wrote:
{quote}OK, is this the following, by [~phansson], or are you referring to
something different?
{quote}
Yes, I am referring to [~phansson] plugins:
[https://bitbucket.org/phansson/netbeansproxy2|https://bitbucket.org/phansson/netbeansnetworkauthenticator]
[https://bitbucket.org/phansson/netbeansnetworkauthenticator]
{quote}Also note that YOU are the NetBeans team, too. :) I.e., please do
provide a PR or state what you are specifically asking for here.
{quote}
Where can I do that? Jira? Sounds like a silly question, but I am not very used
to how participate to large OSS projects :P.
> 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 h
