I don't think it's a good idea for the IDE to alter your ~/.m2/settings.xml, nor should it use some different settings for running Maven from inside the IDE. The user is expected to define their Maven settings themselves.

Note that bug #195296 demonstrates that the embedded Maven (used to parse the POM and eagerly retrieve dependencies, not the CLI Maven used to run builds) uses the IDE's proxy settings.

*** Bug 199112 has been marked as a duplicate of this bug. ***

Could perhaps print a warning at the top of the Output Window when the Maven proxy settings look different from the IDE's. Not clear how reliable this could be since the details of what is supported are likely to differ a little, and the active proxy settings can depend on the activated profile.

It seems that currently the IDE does not make any allowances for proxies with respect to Maven. The proxy settings in the Options window seem to have no effect on how Maven handles proxies, but the user is not informed of this and might be confused. This could be especially true for newer Maven users.

The IDE makes things easy by including Maven, and it seems the embedded Maven will create .m2 if it does not exist. But when behind a proxy, the user will have to edit one of the settings.xml files to create and build projects.

(In reply to comment #5)
> The proxy settings in the Options window seem to have no
> effect on how Maven handles proxies

Correct - Maven has its own system for defining proxies. Since the semantics is a little different from what NB internally supports, probably the best we can do is issue a warning when NB is set to use a proxy and Maven is not, or vice-versa; in the former case, it may be feasible to insert a proxy definition into settings.xml which more or less represents how the IDE is configured.

Ideally Maven would define java.net.useSystemProxies so that when the IDE is configured as per default to follow system proxy settings, the behaviors would match. Unfortunately, in my experience, this flag does not work correctly with Maven (when e.g. MAVEN_OPTS="$MAVEN_OPTS -Djava.net.useSystemProxies=true" is added to ~/.mavenrc on Unix); have not had time to investigate why not.

Docs: c5297d0a3435

*** Bug 189580 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> *** Bug 189580 has been marked as a duplicate of this bug. ***

Note that it's not required to edit settings.xml, Maven accepts command line options such as -DsocksProxyHost and -Dhttp.proxyHost like I mentioned in bug 189580.

(In reply to comment #6)

-Djava.net.useSystemProxies=true seems to be working fine on the command line (e.g. added to Global Execution Options), with or without a Nexus mirror. Investigation of bug #195296 indicates that it would suffice to pass this flag to command-line Maven while relying on the IDE's proxy settings for the embedder.

...though see: http://jira.codehaus.org/browse/MNG-728

In core-main #f3ca74c8524f I added an enhancement - when the following conditions hold:

1. The build failed. (*)

2. The IDE appears to be using a proxy, at least when asked about Maven Central.

3. There are no configured <proxy>s in ~/.m2/settings.xml.

4. -Djava.net.useSystemProxies=true is not already in Global Execution Options.

then a hyperlink is printed at the end of the build in the Output Window suggesting you add -Djava.net.useSystemProxies=true. http://wiki.netbeans.org/FaqMavenProxySettings is also mentioned for background.

I can confirm that this works on Linux/GNOME, and according to documentation it ought to work on Windows as well. I have reports it does nothing on Mac OS X, which might change when an OpenJDK-based release is made. As to other platforms including Solaris I have no information.

Note that this flag picks up the _system_ proxy settings, not any customizations made specifically in the IDE (which defaults to using system proxy settings); and that while it works (on supported systems) for routine artifact download from repositories, it may not work for more unusual network operations from Maven, including uploading releases, especially if these do not use HTTP(S). Will leave things this way for now and get feedback.

A fuller fix would include offering to edit settings.xml to create a <proxy> matching the IDE's current proxy configuration (to the extent that these are comparable, e.g. you are not using a PAC); this would work on more platforms, and would be more likely to work with exotic network code like that in the release plugin, but has the drawback that settings.xml must be modified every time your proxy environment changes - which can be several times a day if you bring a laptop home from work, or go on and off VPN, etc.

Another alternative would be a special IDE option to pass proxy-related system properties to Maven on the fly, as in comment #9, again assuming that the IDE's proxy configuration is limited to things Maven supports; though is not clear to me which properties are interpreted by Maven as direct substitutes for settings.xml#//proxy, as opposed to being interpreted by Java's networking code (and thus subject to the same potential limitations relating to unusual network operations as java.net.useSystemProxies).


(*) Note: the original report shows a build "success" after failing to download the requested archetype, but I think this was simply a bug in an older version of maven-archetype-plugin (switching to a different archetype version in case of error) which was fixed in 2.0 or thereabouts. When I try it today, specifying a nonexistent archetypeVersion results in the expected build failure.

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/f3ca74c8524f
User: Jesse Glick <jglick@netbeans.org>
Log: #194916: prompt to set -Djava.net.useSystemProxies=true if it looks like that could help.

I have a few doubts:

1. Why suggest to use system proxies, instead of the proxies specified in the Netbeans Options? There may be all kinds of reasons why someone would want Netbeans or Maven to use a different proxy server than, say, his web browser.

2. The -Djava.net.useSystemProxies=true option doesn't work on my system, at least. I've tested the proxy detection test class from here [1] on my Fedora 15 system with Gnome 3.0.2:

$ gsettings list-recursively org.gnome.system.proxy
org.gnome.system.proxy autoconfig-url ''
org.gnome.system.proxy ignore-hosts ['localhost', '127.0.0.0/8']
org.gnome.system.proxy mode 'manual'
org.gnome.system.proxy use-same-proxy false
org.gnome.system.proxy.ftp host ''
org.gnome.system.proxy.ftp port 0
org.gnome.system.proxy.http authentication-password ''
org.gnome.system.proxy.http authentication-user ''
org.gnome.system.proxy.http enabled false
org.gnome.system.proxy.http host 'localhost'
org.gnome.system.proxy.http port 8118
org.gnome.system.proxy.http use-authentication false
org.gnome.system.proxy.https host 'localhost'
org.gnome.system.proxy.https port 8118
org.gnome.system.proxy.socks host ''
org.gnome.system.proxy.socks port 0

$ java TestProxy
proxy hostname : DIRECT
No Proxy

$ java -version
java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)

In general, I would say that simply passing on Netbeans' proxy settings to the Maven command line gives a much higher chance of success.

[1] http://www.java-tips.org/java.net/how-to-detect-proxy-settings-for-internet-connection.html

(In reply to comment #14)
> Why suggest to use system proxies, instead of the proxies specified in the
> NetBeans Options?

Because that would be more work which there was no time for, and also see the issues listed under "A fuller fix..." in comment #12.

> There may be all kinds of reasons why someone would want
> NetBeans or Maven to use a different proxy server than, say, his web browser.

There might. There might also be reasons why someone would want NetBeans and Maven to use different proxy settings from each other. In these relatively unusual cases, you can do what you did before: configure a proxy in ~/.m2/settings.xml. The intent of this feature is to make basic Maven builds work out of the box for most people, not to address every corner case.

> -Djava.net.useSystemProxies=true option doesn't work on my system

Pity; have you filed this on bugs.sun.com? It is claimed to pick up GNOME proxy settings.

> with Gnome 3.0.2

I have not yet tested on GNOME 3.

> $ java TestProxy
> proxy hostname : DIRECT
> No Proxy

This does not demonstrate anything unless you actually pass java.net.useSystemProxies to it, does it?

> OpenJDK Runtime Environment (IcedTea6 1.10.3) (fedora-59.1.10.3.fc15-x86_64)

Check also the official JDK.

> http://www.java-tips.org/java.net/how-to-detect-proxy-settings-for-internet-connection.html

Unfortunately this domain does not seem to exist for me.

Hi Jesse,

(In reply to comment #15)

> > Why suggest to use system proxies, instead of the proxies specified in the
> > NetBeans Options?
> 
> Because that would be more work which there was no time for, and also see the
> issues listed under "A fuller fix..." in comment #12.

If it is just a suggestion printed on the console, then it can hardly be more work, can't it?

The drawback of modifying settings.xml in changing proxy environments you mention is true of course, but is not specific to Maven, it does also apply to Netbeans itself.

I know this is a long shot, but given that the Maven settings reference says that properties can be read from external files ( https://maven.apache.org/settings.html#Proxies ) and that Netbeans stores its proxy settings in ~/.netbeans/7.0/config/Preferences/org/netbeans/core.properties, wouldn't it be possible to have Maven pick up Netbeans' current proxy configuration without having to touch settings.xml at all? 
According to the same reference, it is also possible to reference java system properties. If I understand correctly, this means any property passed with a -D parameter.

> ~/.m2/settings.xml. The intent of this feature is to make basic Maven builds
> work out of the box for most people, not to address every corner case.

That is what I'm trying to accomplish as well. :-)

> > -Djava.net.useSystemProxies=true option doesn't work on my system
> 
> Pity; have you filed this on bugs.sun.com? It is claimed to pick up GNOME proxy settings.

I will check if it is filed already.

> > $ java TestProxy
> > proxy hostname : DIRECT
> > No Proxy
> 
> This does not demonstrate anything unless you actually pass
> java.net.useSystemProxies to it, does it?

That's done in the code. The site seems to be down right now so I'll attach the test source.

Created attachment 110354 [details]
Program to print the current proxy configuration to standard output

(In reply to comment #16)
> If it is just a suggestion printed on the console, then it can hardly be more
> work, can't it?

Sure, can suggest to do that, but that is not very helpful compared to actually making the change.

> The drawback of modifying settings.xml in changing proxy environments you
> mention is true of course, but is not specific to Maven, it does also apply to
> NetBeans itself.

But the default IDE behavior is to pick up the system proxy settings. (Currently this is a bit broken in that it considers system settings only at startup, so you need to restart the IDE if you change proxies.)

> I know this is a long shot, but given that the Maven settings reference says
> that properties can be read from external files (
> https://maven.apache.org/settings.html#Proxies )

Uh, where does it say that?

> According to the same reference, it is also possible to reference java system
> properties. If I understand correctly, this means any property passed with a -D
> parameter.

Right... but that means that settings.xml will not work for running Maven outside the IDE unless you pass some values for all these properties.

Checked with the attached program and it works correctly on Ubuntu Lucid, so a lack of support for GNOME 3 seems the most likely explanation. If true, that is probably something that could be fixed easily even in a 1.6.0_xx update.

(In reply to comment #18)

> Sure, can suggest to do that, but that is not very helpful compared to actually
> making the change.

Agreed.
 
> But the default IDE behavior is to pick up the system proxy settings.
> (Currently this is a bit broken in that it considers system settings only at
> startup, so you need to restart the IDE if you change proxies.)

Is this a filed Netbeans issue?

> > I know this is a long shot, but given that the Maven settings reference says
> > that properties can be read from external files (
> > https://maven.apache.org/settings.html#Proxies )
> 
> Uh, where does it say that?

Under 'Properties':
5. x: Set within a <properties /> element or an external files, the value may be used as ${someVar}.

Unfortunately, it does not say where to define such an external file.

> Right... but that means that settings.xml will not work for running Maven
> outside the IDE unless you pass some values for all these properties.

Yes, that is a significant drawback. However, properties are profile-dependent, so perhaps Netbeans could pass on a -P option to Maven when running it from within the IDE.

> Checked with the attached program and it works correctly on Ubuntu Lucid, so a
> lack of support for GNOME 3 seems the most likely explanation. If true, that is
> probably something that could be fixed easily even in a 1.6.0_xx update.

I have filed https://bugzilla.redhat.com/show_bug.cgi?id=735336 about the system proxy settings under Gnome. If necessary I will escalate the issue to the Java bug database.

(In reply to comment #19)
>> [the IDE] considers system settings only at
>> startup, so you need to restart the IDE if you change proxies.
> 
> Is this a filed NetBeans issue?

Not that I know of.

> Under 'Properties':

I think this is meant to apply to <profiles>, not <proxies>, and a profile apparently cannot override proxy settings, so this looks like a dead end.

(In reply to comment #20)

> Not that I know of.

Filed http://netbeans.org/bugzilla/show_bug.cgi?id=201731 .

> > Under 'Properties':
> 
> I think this is meant to apply to <profiles>, not <proxies>, and a profile
> apparently cannot override proxy settings, so this looks like a dead end.

That's a pity. Another approach then could be to use Maven's --global-settings parameter to point it to the Netbeans-specific settings.xml file? The /java/modules/ext/maven/settings.xml file under the Netbeans installation directory is currently unused, as far as I can determine.

(In reply to comment #21)
> use Maven's --global-settings parameter

No.

> /java/modules/ext/maven/settings.xml file under the Netbeans installation
> directory is currently unused, as far as I can determine.

It is consulted by Maven before ~/.m2/settings.xml.

(In reply to comment #22)

> No.
> 
> > /java/modules/ext/maven/settings.xml file under the Netbeans installation
> > directory is currently unused, as far as I can determine.
> 
> It is consulted by Maven before ~/.m2/settings.xml.

Right. But it just contains an empty <settings> element, at least on my system. So either this is the perfect opportunity to pass on netbeans settings to Maven without interfering with Maven execution from the command line, or it serves some other purpose that I'm not aware of. In any case, that's the best I can come up with for now. Thanks for your attention.

(In reply to comment #23)
> it just contains an empty <settings> element

By default. But it can be edited - in which case Maven merges "global" and "user" settings. (As of 7.1, it is also honored by the IDE's embedder, used for everything other than launching actual builds.)

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