This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 211387 - [72cat] Cannot download Javadoc or sources from context menu
Summary: [72cat] Cannot download Javadoc or sources from context menu
Status: REOPENED
Alias: None
Product: projects
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.1.1
Hardware: PC Windows XP
: P3 normal with 6 votes (vote)
Assignee: Tomas Stupka
URL:
Keywords:
: 219415 233170 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-04-18 11:53 UTC by jmborer
Modified: 2018-08-23 11:47 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
screenshot (362.21 KB, image/png)
2012-04-23 07:49 UTC, Milos Kleint
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jmborer 2012-04-18 11:53:40 UTC
Almost the same issue as described in http://netbeans.org/bugzilla/show_bug.cgi?id=186787

Downloading sources and javadocs with mvn dependency:resolve works flawlessly but doing it via the context menu in the project view I get:

INFO [org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultHttpClient]: I/O exception (java.net.SocketException) caught when connecting to the target host: Malformed reply from SOCKS server

We have an internal maven proxy and use the following config in our setting.xml file:

    <mirrors>
        <mirror>
            <id>artifactory</id>
            <mirrorOf>*</mirrorOf>
            <url>http://inch-forge.skyguide.corp/artifactory/repos</url>
            <name>Artifactory</name>
        </mirror>
    </mirrors>

As far as I remember it worked on 6.9. Since, we changed our settings.xml file to use <mirrors>. Might be the problem...
Comment 1 Milos Kleint 2012-04-18 12:04:22 UTC
what build of 7.2dev are you using? I've done quite some work in this are lately. Indeed proxies were ignored in some scenarios and sometimes mirrors were ignored as well.

so you have just mirrors or also proxies defined? (I've just only mirror at home and only proxies at oracle office) both seem to be working right now in latest dev for me.
Comment 2 Milos Kleint 2012-04-18 12:18:18 UTC
see issues 209499, mirrors and proxies were not taken into account in some cases.
Comment 3 jmborer 2012-04-18 12:20:49 UTC
I just downloaded today the dev build. I am using mirror to proxy through our
maven proxy repository. Does it answer your question?
Comment 4 Milos Kleint 2012-04-18 12:32:29 UTC
I've just tried with my local copy of nexus and it seems to be working fine.

can you try replacing your artifactory with this nexus url (which I hope mirrors central as well)
https://oss.sonatype.org/content/groups/public/


here are the settings.xml snippets I used:
<mirrors>
    <mirror>
        <id>my-local-nexus</id>
        <mirrorOf>*</mirrorOf>
        <url>http://localhost:8081/nexus/content/groups/public/</url>
    </mirror>
</mirrors>
<proxies>
    <proxy>
        <active>true</active>
        <host>localhost</host>
        <port>1111</port>
        <protocol>http</protocol>
        <nonProxyHosts>localhost</nonProxyHosts>
    </proxy>
</proxies>

the proxy definition's intention is to have all connections hit the wall with exception of the localhost ones. That way I can ensure that the artifact was not retrieved from central directly. And indeed, when I remove the mirror, Download Declared Dependencies, Download Sources/Javadoc actions do nothing/get stuck. With the mirror defined, I get the content just fine. When resolving the dependencies (Download Declared Dependencies, maven creates _maven.repositories files in local repository and these appear to indicate as well that just my mirror was contacted.
Comment 5 jmborer 2012-04-20 11:20:31 UTC
Back in my dev env.

I tried with an empty local repository to create a project with:

<proxies>
        <proxy>
            <active>true</active>
            <protocol>http</protocol>
            <host>myproxy</host>
            <port>8080</port>
            <username>somename</username>
            <password>somepassword</password>
            <nonProxyHosts>localhost</nonProxyHosts>
        </proxy>
    </proxies>
    <mirrors>
        <mirror>
            <id>artifactory</id>
            <mirrorOf>*</mirrorOf>
            <url>https://oss.sonatype.org/content/groups/public/</url>
            <name>Artifactory</name>
        </mirror>
    </mirrors>

Without the mirror, it worked. With this mirror: even the first artifact could not be downloaded.

Anyway I retried with my onw maven proxy, empty local repository and the following settings.xml:

<mirrors>
        <mirror>
            <id>artifactory</id>
            <mirrorOf>*</mirrorOf>
            <url>http://inch-forge.skyguide.corp/artifactory/repos</url>
            <name>Artifactory</name>
        </mirror>
    </mirrors>

Then I created a new Maven project. All dependencies could be downloaded. After that I added a dependency to Velocity:

<dependency>
    <groupId>org.apache.velocity</groupId>
    <artifactId>velocity</artifactId>
    <version>1.6.3</version>
</dependency>

NB was able to download the dependency as well as its javadoc and sources. Finally I added a dependency to one of our internal libraries. This library has sources but not javadoc. Downloading the sources worked, but when I requested the javadoc download, it remained stuck for a while and finally I get:

INFO [org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultHttpClient]: I/O exception (java.net.SocketException) caught when connecting to the target host: Malformed reply from SOCKS server
INFO [org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultHttpClient]: Retrying connect


On the server I can clearly see the request:
20120420111440|32|REQUEST|156.135.81.211|non_authenticated_user|GET|/repos/ch/skyguide/nimbus/nimbus-core/1.2.8/nimbus-core-1.2.8-javadoc.jar|HTTP/1.1|404|0

Where you can notice that the javadoc was not found: 404 error. 

Somehow this seems to be the problem: NB maven tries to retrieve a resources that doesn't exist (-> 404 error) but sees that as a "Malformed reply from SOCKS server" response. Then it retries several times before aborting the retrieval. Do that for ~20 files and you will get your "download javadoc" stuck for a good while...
Comment 6 jmborer 2012-04-20 11:24:31 UTC
This is the raw response header when a file is not found:

HTTP/1.1 404 Introuvable

Server: Artifactory/2.5.1.1

Content-Type: text/html;charset=utf-8

Content-Length: 1029

Date: Fri, 20 Apr 2012 11:22:01 GMT

<html><head><title>Apache Tomcat/6.0.26 - Rapport d'erreur</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>Etat HTTP 404 - Could not find resource</h1><HR size="1" noshade="noshade"><p><b>type</b> Rapport d'état</p><p><b>message</b> <u>Could not find resource</u></p><p><b>description</b> <u>La ressource demandée (Could not find resource) n'est pas disponible.</u></p><HR size="1" noshade="noshade"><h3>Apache Tomcat/6.0.26</h3></body></html>
Comment 7 jmborer 2012-04-20 11:36:09 UTC
As you can see there is some french in the headers. I'll to change the locale on the PC hosting the Maven proxy to make it use english.
Comment 8 Milos Kleint 2012-04-20 11:42:06 UTC
all that we do is delegating to maven itself to download the artifacts, the "maven way". As can be seen in the org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultHttpClient log line.

I'm wondering if that's some sort of interaction problem between maven and it's http client codebase, your proxy server and artifactory.

I wonder if we could reproduce on cmd line by adding a non existing dependency for example..


in here:
On the server I can clearly see the request:
20120420111440|32|REQUEST|156.135.81.211|non_authenticated_user|GET|/repos/ch/skyguide/nimbus/nimbus-core/1.2.8/nimbus-core-1.2.8-javadoc.jar|HTTP/1.1|404|0

the 156.135.81.211 IP address is the address of the proxy server? in other words can we be sure that the connection went through the proxy?
Comment 9 jmborer 2012-04-20 11:48:41 UTC
Same behavior even though heaer is now:

HTTP/1.1 404 Not Found
Server: Artifactory/2.5.1.1
Content-Type: text/html;charset=utf-8
Content-Length: 1021
Date: Fri, 20 Apr 2012 11:48:25 GMT
Comment 10 jmborer 2012-04-20 11:55:31 UTC
156.135.81.211 is the requester's IP adress (my dev computer). The problem really seems related to the fact it doesn't find the javadoc for an existing dependency. 

Indeed adding a non existing dependency also blocks through the call of "Download declared dependencies" on the dependencies node in the project where when I try to build, Maven exits quickly with an error:


Failed to execute goal on project mavenproject3: Could not resolve dependencies for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]
Comment 11 Milos Kleint 2012-04-20 12:06:21 UTC
(In reply to comment #10)
> 156.135.81.211 is the requester's IP adress (my dev computer). The problem
> really seems related to the fact it doesn't find the javadoc for an existing
> dependency. 
> 
> Indeed adding a non existing dependency also blocks through the call of
> "Download declared dependencies" on the dependencies node in the project where
> when I try to build, Maven exits quickly with an error:

and that's maven 3.0.4, right?

> 
> 
> Failed to execute goal on project mavenproject3: Could not resolve dependencies
> for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find
> artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory
> (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]

a bit clueless what's going on here.. I'm not sure I would be able to make sense of it without having a working example setup..  

any proxy settings in the IDE?
Comment 12 jmborer 2012-04-20 12:08:17 UTC
Another thing I've noticed is that when I cleanup my local repository again,
restore the POM with valid dependencies and then choose "Download declared
dependencies" on the dependencies node, only the direct dependencies are
downloaded. No problem to get sources or javadoc for those when they exist. Now
when I build the project, then only, I get all the inherited dependencies
(those in gray).
Comment 13 jmborer 2012-04-20 12:09:56 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > 156.135.81.211 is the requester's IP adress (my dev computer). The problem
> > really seems related to the fact it doesn't find the javadoc for an existing
> > dependency. 
> > 
> > Indeed adding a non existing dependency also blocks through the call of
> > "Download declared dependencies" on the dependencies node in the project where
> > when I try to build, Maven exits quickly with an error:
> 
> and that's maven 3.0.4, right?

Nope 3.0.3

> 
> > 
> > 
> > Failed to execute goal on project mavenproject3: Could not resolve dependencies
> > for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find
> > artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory
> > (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]
> 
> a bit clueless what's going on here.. I'm not sure I would be able to make
> sense of it without having a working example setup..  

Well I added a non existing dependency to see how Maven and NB react: 

* NB remains stuck to download the dependency (like for javadoc)
* Maven fails with this error
> 
> any proxy settings in the IDE?
Comment 14 jmborer 2012-04-20 12:12:22 UTC
(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > 156.135.81.211 is the requester's IP adress (my dev computer). The problem
> > > really seems related to the fact it doesn't find the javadoc for an existing
> > > dependency. 
> > > 
> > > Indeed adding a non existing dependency also blocks through the call of
> > > "Download declared dependencies" on the dependencies node in the project where
> > > when I try to build, Maven exits quickly with an error:
> > 
> > and that's maven 3.0.4, right?
> 
> Nope 3.0.3
> 
> > 
> > > 
> > > 
> > > Failed to execute goal on project mavenproject3: Could not resolve dependencies
> > > for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find
> > > artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory
> > > (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]
> > 
> > a bit clueless what's going on here.. I'm not sure I would be able to make
> > sense of it without having a working example setup..  
> 
> Well I added a non existing dependency to see how Maven and NB react: 
> 
> * NB remains stuck to download the dependency (like for javadoc)
> * Maven fails with this error
> > 
> > any proxy settings in the IDE?

Yes. If I try to use the system settings, it doesn't work even though my Chrome does the same and it works!?
Comment 15 jmborer 2012-04-20 12:17:18 UTC
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > 156.135.81.211 is the requester's IP adress (my dev computer). The problem
> > > > really seems related to the fact it doesn't find the javadoc for an existing
> > > > dependency. 
> > > > 
> > > > Indeed adding a non existing dependency also blocks through the call of
> > > > "Download declared dependencies" on the dependencies node in the project where
> > > > when I try to build, Maven exits quickly with an error:
> > > 
> > > and that's maven 3.0.4, right?
> > 
> > Nope 3.0.3
> > 
> > > 
> > > > 
> > > > 
> > > > Failed to execute goal on project mavenproject3: Could not resolve dependencies
> > > > for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find
> > > > artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory
> > > > (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]
> > > 
> > > a bit clueless what's going on here.. I'm not sure I would be able to make
> > > sense of it without having a working example setup..  
> > 
> > Well I added a non existing dependency to see how Maven and NB react: 
> > 
> > * NB remains stuck to download the dependency (like for javadoc)
> > * Maven fails with this error
> > > 
> > > any proxy settings in the IDE?
> 
> Yes. If I try to use the system settings, it doesn't work even though my Chrome
> does the same and it works!?

I double checked: use "System settings" doesn't work at all

INFO [org.netbeans.core.ProxyAutoConfig]: findProxyForURL(socket://download.oracle.com:80) returns null.

Overriding with my own settings taking care to bypass *.skyguide.corp works fine. I can see the "Start Page" with all its content.
Comment 16 jmborer 2012-04-20 12:36:11 UTC
I downloaded and installed Maven 3.0.4. Then I deleted my local repository and finally ran through Custom -> Goal...

mvn dependency:resolve -Dclassifier=javadoc

It took some time was a little bit blocked when trying to get the missing javadocs (maybe something like 6  seconds per request what seems normal when checking several remote sites), but never that long as when trying to retrieve the docs through the "Download Javadoc" menu item.
Comment 17 jmborer 2012-04-20 12:38:37 UTC
What command are you exactly trying to execute with "Download Javadoc"?
Comment 18 Milos Kleint 2012-04-20 13:13:26 UTC
(In reply to comment #12)
> Another thing I've noticed is that when I cleanup my local repository again,
> restore the POM with valid dependencies and then choose "Download declared
> dependencies" on the dependencies node, only the direct dependencies are
> downloaded. No problem to get sources or javadoc for those when they exist. Now
> when I build the project, then only, I get all the inherited dependencies
> (those in gray).

http://hg.netbeans.org/core-main/rev/c802d0407fa7
Comment 19 Milos Kleint 2012-04-20 13:25:38 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > (In reply to comment #11)
> > > > (In reply to comment #10)
> > > > > Failed to execute goal on project mavenproject3: Could not resolve dependencies
> > > > > for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find
> > > > > artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory
> > > > > (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]
> > > > 
> > > > a bit clueless what's going on here.. I'm not sure I would be able to make
> > > > sense of it without having a working example setup..  
> > > 
> > > Well I added a non existing dependency to see how Maven and NB react: 
> > > 
> > > * NB remains stuck to download the dependency (like for javadoc)
> > > * Maven fails with this error
> > > > 
> > > > any proxy settings in the IDE?
> > 
> > Yes. If I try to use the system settings, it doesn't work even though my Chrome
> > does the same and it works!?
> 
> I double checked: use "System settings" doesn't work at all
> 
> INFO [org.netbeans.core.ProxyAutoConfig]:
> findProxyForURL(socket://download.oracle.com:80) returns null.
> 
> Overriding with my own settings taking care to bypass *.skyguide.corp works
> fine. I can see the "Start Page" with all its content.


interesting.. maybe the IDE's proxy settings are at fault.. can you try again to download in the IDE this time, but before doing so, set the IDE to use no proxies (and therefore only have the maven settings, which we know are correct)
Comment 20 Milos Kleint 2012-04-20 13:34:54 UTC
I can confirm that *all* in VM network traffic, including the maven related requests go through the IDE's own proxy settings.

org.netbeans.core.NbClassSelector is the class that handles IDE's proxy settings..
Comment 21 jmborer 2012-04-20 13:35:30 UTC
(In reply to comment #19)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #13)
> > > > (In reply to comment #11)
> > > > > (In reply to comment #10)
> > > > > > Failed to execute goal on project mavenproject3: Could not resolve dependencies
> > > > > > for project ch.skyguide.inch:mavenproject3:jar:1.0-SNAPSHOT: Could not find
> > > > > > artifact ch.skyguide.nimbus:nimbus-corer:jar:1.2.10 in artifactory
> > > > > > (http://inch-forge.skyguide.corp/artifactory/repos) -> [Help 1]
> > > > > 
> > > > > a bit clueless what's going on here.. I'm not sure I would be able to make
> > > > > sense of it without having a working example setup..  
> > > > 
> > > > Well I added a non existing dependency to see how Maven and NB react: 
> > > > 
> > > > * NB remains stuck to download the dependency (like for javadoc)
> > > > * Maven fails with this error
> > > > > 
> > > > > any proxy settings in the IDE?
> > > 
> > > Yes. If I try to use the system settings, it doesn't work even though my Chrome
> > > does the same and it works!?
> > 
> > I double checked: use "System settings" doesn't work at all
> > 
> > INFO [org.netbeans.core.ProxyAutoConfig]:
> > findProxyForURL(socket://download.oracle.com:80) returns null.
> > 
> > Overriding with my own settings taking care to bypass *.skyguide.corp works
> > fine. I can see the "Start Page" with all its content.
> 
> 
> interesting.. maybe the IDE's proxy settings are at fault.. can you try again
> to download in the IDE this time, but before doing so, set the IDE to use no
> proxies (and therefore only have the maven settings, which we know are correct)


Cleared local repo, set NB to use no proxy.

Build: OK
Download Javadoc: OK and no longer any long blocking time. Seems to work as in
the past. Houra!
Comment 22 jmborer 2012-04-20 13:38:38 UTC
(In reply to comment #20)
> I can confirm that *all* in VM network traffic, including the maven related
> requests go through the IDE's own proxy settings.
> 
> org.netbeans.core.NbClassSelector is the class that handles IDE's proxy
> settings..

But then why does the proxy option "Use system settings" settings not work? The JVM itself uses the Internet Settings on windows as well as the NTLM crendentials (that, I can guarantee). The only HttpClient stack I know of where you can provide your own proxy authentication that really works is HttpClient from Apache.
Comment 23 jmborer 2012-04-20 13:55:31 UTC
A last thing, I would never have complained about this missing javadoc issue if NB had not eventually triggered a download of the sources and docs of all my dependencies. I wonder if this should really made automatically or only on demand if for example:
1) a user executes "Download Javadoc" or "Download sources"
2) a user tries to browse code of a dependency, then only NB should try to download the sources and if unsuccessful do the "decompilation" of the binary.

What do you think? Wouldn't it be more clever that way?
Comment 24 Milos Kleint 2012-04-20 14:06:32 UTC
(In reply to comment #23)
> A last thing, I would never have complained about this missing javadoc issue if
> NB had not eventually triggered a download of the sources and docs of all my
> dependencies. I wonder if this should really made automatically or only on
> demand if for example:
> 1) a user executes "Download Javadoc" or "Download sources"

that's what we already do. additionally there are some global settings that allow semi-automated download of sources and javadoc. These could be enhanced to attempt download on any maven pom edit. I think an issue is filed for it..

> 2) a user tries to browse code of a dependency, then only NB should try to
> download the sources and if unsuccessful do the "decompilation" of the binary.
> 

this is a bit problematic, browsing is not the primary usecase for sources, maven projects provide a query implementation for everyone else and we need to return fast -because don't know who's asking and how much time he has in the first place. On top of that we would need to introduce some sort of caching for failed downloads and then all starts to be a bit messy and unpredictable.
Comment 25 Jesse Glick 2012-04-20 15:18:40 UTC
(In reply to comment #20)
> *all* in VM network traffic, including the maven related
> requests go through the IDE's own proxy settings.

This surprises me. For Maven 3.0.3, using lightweight HTTP client (java.net.HTTPURLConnection), I would expect that; but 3.0.4 uses Apache HttpComponents, which ought to be ignoring the standard Java proxy settings entirely. (Meaning the partial fix of bug #194916 is probably useless in 7.2.)
Comment 26 Milos Kleint 2012-04-20 16:17:16 UTC
(In reply to comment #25)
> (In reply to comment #20)
> > *all* in VM network traffic, including the maven related
> > requests go through the IDE's own proxy settings.
> 
> This surprises me. For Maven 3.0.3, using lightweight HTTP client
> (java.net.HTTPURLConnection), I would expect that; but 3.0.4 uses Apache
> HttpComponents, which ought to be ignoring the standard Java proxy settings
> entirely. (Meaning the partial fix of bug #194916 is probably useless in 7.2.)

Not entirely sure if really *all*, but a breakpoint in NbClassSelector was reached for me when I triggered "Download javadoc" or "Download dependencies" actions. and the proxy settings there was applied on the url.
Comment 27 Jesse Glick 2012-04-20 16:34:44 UTC
(In reply to comment #26)
> a breakpoint in NbClassSelector [NbProxySelector?] was
> reached for me when I triggered "Download javadoc" or "Download dependencies"

So was something in Maven using HTTPURLConnection, or was this triggered for some other reason? Check the call stack.
Comment 28 jmborer 2012-04-20 16:51:56 UTC
(In reply to comment #27)
> (In reply to comment #26)
> > a breakpoint in NbClassSelector [NbProxySelector?] was
> > reached for me when I triggered "Download javadoc" or "Download dependencies"
> 
> So was something in Maven using HTTPURLConnection, or was this triggered for
> some other reason? Check the call stack.

Well I must say that maven alone works without a glitch. It uses it's own proxy configs from settings.xml properly. The problem I ran into is when the command "download javadoc" with maven is called.
Comment 29 Quality Engineering 2012-04-21 09:58:22 UTC
Integrated into 'main-golden', will be available in build *201204210400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/c802d0407fa7
User: Milos Kleint <mkleint@netbeans.org>
Log: #211387 readProjectWithDependencies should not have the workspacereader set all the time, eg. when downloading dependencies it should be off.
Comment 30 Milos Kleint 2012-04-23 07:49:02 UTC
Created attachment 118609 [details]
screenshot

apparently the http client from maven is using the socket protocol when reaching the NbProxySelector class, in my case it did resolve to no proxy. (I had the http proxy set in the main options dialog - not "more" button dialog).

If I enter the socks proxy as well to some non existing url, the downloads hang immediately for me. That's an indication that the reporter probably needs to set/unset the socks proxy in netbeans.. 

not sure if that's expected behaviour or not.
Comment 31 Jesse Glick 2012-04-23 12:52:13 UTC
(In reply to comment #30)
> apparently the http client from maven is using the socket protocol when
> reaching the NbProxySelector class

As in "socket://the.mirror.repo:80"? So this is an indication that Apache HttpComponents is being routed through NbProxySelector without its knowledge or consent - probably a problem, since any desired proxy configuration would already have been applied by Maven.

I think NbProxySelector needs to return NO_PROXY in this situation. Skipping any socket-protocol URI seems too extreme, since there might be some IDE component which attempts to make a non-HTTP(S) request to the Internet (though I cannot think of any example). A more limited fix would be to look for org.apache.maven.wagon.providers.http.httpclient.** classes in the call stack.
Comment 32 jmborer 2012-04-23 12:57:40 UTC
(In reply to comment #30)
> Created attachment 118609 [details]
> screenshot
> 
> apparently the http client from maven is using the socket protocol when
> reaching the NbProxySelector class, in my case it did resolve to no proxy. (I
> had the http proxy set in the main options dialog - not "more" button dialog).
> 
> If I enter the socks proxy as well to some non existing url, the downloads hang
> immediately for me. That's an indication that the reporter probably needs to
> set/unset the socks proxy in netbeans.. 
> 
> not sure if that's expected behaviour or not.

If you mean by "the reporter" myself, then I can tell you that the "Use the same proxy for all protocols" is checked.
Comment 33 Milos Kleint 2012-05-04 11:57:04 UTC
one idea we had with jrechtacek was to append a query part to url eg. ?netbeans=no_proxy,

unfortunately it feels impossible to get behind the weird guice/sisu/plexus wiring of maven to pick a maven/wagon/aether component to replace and append the query to the url at hand. Not even sure it will make any difference for socket:// protocol..
Comment 34 jmborer 2012-05-04 12:00:16 UTC
Then why did it work in older versions of NB?
Comment 35 Milos Kleint 2012-05-04 12:03:25 UTC
(In reply to comment #34)
> Then why did it work in older versions of NB?

you mean the 6.9 you mentioned in the bug description? many moving parts since then, different maven codebase, different proxy selector code, maybe even different jdk one is running on. very hard to tell..
Comment 36 jmborer 2012-05-04 12:12:39 UTC
May be I found a usable workaround: I unset the SOCKS proxy settings by unchecking "Use the same proxy for all protocols" check box and leaving the SOCKS field empty. Since then log seems no longer to block on some URLs. However I get that kind of error messages in my IDE logs:

INFO [org.netbeans.core.NbProxySelector]: Incomplete SOCKS Server [/] found in ProxySelector[Type: 2] for uri socket://repo.maven.apache.org:80.
Comment 37 Milos Kleint 2012-05-04 12:20:57 UTC
(In reply to comment #33)
> one idea we had with jrechtacek was to append a query part to url eg.
> ?netbeans=no_proxy,
> 
> unfortunately it feels impossible to get behind the weird guice/sisu/plexus
> wiring of maven to pick a maven/wagon/aether component to replace and append
> the query to the url at hand. Not even sure it will make any difference for
> socket:// protocol..

and actually the socket:// url is constructed by the socket impl in jdk, so no way to intercept anyway..
Comment 38 Jiri Rechtacek 2012-05-04 12:30:59 UTC
(In reply to comment #36)
> May be I found a usable workaround: I unset the SOCKS proxy settings by
> unchecking "Use the same proxy for all protocols" check box and leaving the
> SOCKS field empty. Since then log seems no longer to block on some URLs.
Right. It means that NbProxySelector returns NO_PROXY for all socket connections.

> However I get that kind of error messages in my IDE logs:
> 
> INFO [org.netbeans.core.NbProxySelector]: Incomplete SOCKS Server [/] found in
> ProxySelector[Type: 2] for uri socket://repo.maven.apache.org:80.
Don't care about it, it's just information that some of types of proxy are filled-out and some not.
Comment 39 jmborer 2012-05-04 12:32:38 UTC
There is something I still don't understand: according to Jesse, Maven now uses
the HTTPClient socket stack. This stack completely bypasses the JDK socket
creation. I could check that a few years ago. I used a soft that was using
HttpClient from apache and where I could provide my own proxy and
authentication parameters where the JVM socket was always using the credentials
of the logged user whatever you tried to configure.
Comment 40 jmborer 2012-05-04 12:36:07 UTC
Let me understand: SOCKS doesn't mean "socket" (check http://en.wikipedia.org/wiki/SOCKS) but is a specific proxy authentication type. Here we try to build a http/https request. I should ignore everything related to SOCKS and should use the settings related http/https proxy.
Comment 41 Jesse Glick 2012-05-04 15:48:54 UTC
(In reply to comment #39)
> according to Jesse, Maven now uses
> the HTTPClient socket stack. This stack completely bypasses the JDK socket
> creation.

No, what I said is that it bypasses java.net.HTTPURLConnection and its machinery. It still uses the lower-level java.net.Socket AFAIK. And when you have a SOCKS proxy configured the JRE socket implementation will apparently ask the proxy selector about all socket connections (not necessarily HTTP).

Did you try having NbProxySelector check for httpclient in the call stack? Crude, I know, but easy enough and might suffice.
Comment 42 jmborer 2012-05-23 10:45:40 UTC
Hi Jesse,

Is your request addressed to me? I am not currently able to debug that.

(In reply to comment #41)

> (In reply to comment #39)
> > according to Jesse, Maven now uses
> > the HTTPClient socket stack. This stack completely bypasses the JDK socket
> > creation.
> 
> No, what I said is that it bypasses java.net.HTTPURLConnection and its
> machinery. It still uses the lower-level java.net.Socket AFAIK. And when you
> have a SOCKS proxy configured the JRE socket implementation will apparently ask
> the proxy selector about all socket connections (not necessarily HTTP).
> 
> Did you try having NbProxySelector check for httpclient in the call stack?
> Crude, I know, but easy enough and might suffice.
Comment 43 Jesse Glick 2012-05-24 02:38:53 UTC
Comment #41 was addressed to mkleint / jrechtacek. Sorry for confusion.
Comment 44 gary003g 2012-06-15 18:27:27 UTC
(In reply to comment #36)
> May be I found a usable workaround: I unset the SOCKS proxy settings by
> unchecking "Use the same proxy for all protocols" check box and leaving the
> SOCKS field empty. 
Where have you done that. I am having the same problem and can't find this checkbox in options.
Comment 45 gary003g 2012-06-15 18:29:02 UTC
(In reply to comment #36)
> May be I found a usable workaround: I unset the SOCKS proxy settings by
> unchecking "Use the same proxy for all protocols" check box and leaving the
> SOCKS field empty. 
Where have you done that. I am having the same problem and can't find this checkbox in options.
Comment 46 jmborer 2012-06-18 11:08:21 UTC
1) Go to Tools>Options>General
2) Set Proxy settings to "Manual Proxy settings" and fill with your data.
3) Click on "More" button

In the Advanced Proxy Options
1) uncheck the "Use the same proxy settings for all protocols" check box
2) clear the "SOCKS Proxy" text field. I must be blank. The others contain the same info as the "HTTP Proxy" text field.
Comment 47 beginner_ 2012-10-05 08:32:48 UTC
*** Bug 219415 has been marked as a duplicate of this bug. ***
Comment 48 Milos Kleint 2012-11-30 13:50:13 UTC
an API that would do something along the lines of NoProxy.runWithoutProxyInterception(Runnable) would be great.
However aether's WagonRepositoryConnector uses ThreadPoolExecutor to perform some networking concurrently, for this particular case including child threads in proxy interception should help (eg. via InheritableThreadLocal would help).
Comment 49 Milos Kleint 2013-01-09 13:08:08 UTC
I've tried to come up with a way to have user notified that SOCKS proxy is defined and that it differs from the maven proxies, however I had a hard time figuring the actual final hostnames that will get contacted by maven in order to construct a socket://<hostname> url and test it against org.openide.util.NetworksSettings..
not for 7.3, stil no proper solution in sight.
Comment 50 Milos Kleint 2013-07-24 14:25:24 UTC
*** Bug 233170 has been marked as a duplicate of this bug. ***
Comment 51 markiewb 2013-12-18 18:27:41 UTC
Is it worth to put an entry about this into the release notes in the section known issues?!
Comment 52 Martin Balin 2016-07-07 08:38:13 UTC
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss
Comment 53 bugmenot1 2017-05-24 10:38:18 UTC
Current dev build is still affected.

I don’t use a proxy (NetBeans is set to ‘No Proxy’), but I use a mirror configured in my %userprofile%\.m2\settings.xml.

The mirror uses HTTPS and I have set -Djavax.net.ssl.trustStore=… in NetBeans’ settings (Java > Maven > Execution > Global Execution Options). Downloading dependencies works fine, but not Javadoc and sources. Same problem with bundled Maven from NetBeans 8.2 and external Maven (3.5.0).

I can download Javadoc and sources using
mvn dependency:sources
mvn dependency:resolve -Dclassifier=javadoc
but when trying to download them in NetBeans, nothing happens except the status bar shows ‘Downloading Sources’/‘Downloading Javadoc’ for a short moment (maybe a second). I don’t see any error message.

Product Version: NetBeans IDE Dev (Build 201705230001)
Java: 1.8.0_121; Java HotSpot(TM) 64-Bit Server VM 25.121-b13
Runtime: Java(TM) SE Runtime Environment 1.8.0_121-b13
System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (nb)
Comment 54 bugmenot1 2017-05-31 11:09:37 UTC
I figured out that this seems to be a problem with the truststore handling in NetBeans. If I change the URLs of the mirror in .m2\settings.xml to use plain HTTP, downloading sources and Javadoc works.

HTTPS now works if I edit netbeans-install-dir\etc\netbeans.conf and
add -J-Djavax.net.ssl.trustStore=C:/path/to/truststore.jks to netbeans_default_options.

However, I think this shouldn’t be necessary because I use an external Maven installation and already added -Djavax.net.ssl.trustStore=… to the Maven Global Execution Options in NetBeans and added it to MAVEN_OPTS in home-directory\.mavenrc.

At least there should be a message to the user that the connection failed due to the certificate validation failure.
Comment 55 tilman 2018-08-23 11:47:52 UTC
Same for me, I just installed NB 8.2 on a new PC at work without importing the settings of the old one. Changing maven versions didn't help.

The solution explained by jmborer in the message of "2012-06-18 11:08:21 UTC" worked (my problem was downloading the maven repository index, so that CTRL-Tab in a pom.xml file would show what versions are available). And after that I noticed that the same change had also been done in the old PC.