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.
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...
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.
see issues 209499, mirrors and proxies were not taken into account in some cases.
I just downloaded today the dev build. I am using mirror to proxy through our maven proxy repository. Does it answer your question?
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.
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...
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>
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.
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?
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
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]
(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?
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).
(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?
(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!?
(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.
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.
What command are you exactly trying to execute with "Download Javadoc"?
(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
(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)
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..
(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!
(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.
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?
(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.
(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.)
(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.
(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.
(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.
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.
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.
(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.
(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.
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..
Then why did it work in older versions of NB?
(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..
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.
(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..
(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.
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.
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.
(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.
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 #41 was addressed to mkleint / jrechtacek. Sorry for confusion.
(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.
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.
*** Bug 219415 has been marked as a duplicate of this bug. ***
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).
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.
*** Bug 233170 has been marked as a duplicate of this bug. ***
Is it worth to put an entry about this into the release notes in the section known issues?!
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
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)
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.
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.