We Keep Coding

Use Maven behind Proxy

I'm trying to set up a Maven project with NetBeans on a machine behind a proxy.
When I try to build the dependencies, I get the following error:
Plugin org.apache.maven.plugins:maven-dependency-plugin:2.6 or one of
its dependencies could not be resolved: Failed to read artifact
descriptor for
org.apache.maven.plugins:maven-dependency-plugin:jar:2.6: Could not
transfer artifact
org.apache.maven.plugins:maven-dependency-plugin:pom:2.6 from/to
central (https://repo.maven.apache.org/maven2):
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target -> [Help 1]
As stated here, it's probably because of my proxy configuration.
Netbeans itself has access to the internet. Loading plugins etc. works:
A possible solution would be setting the proxy settings in settings.xml:
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>user</username>
<password>****</password>
<host>proxy</host>
<port>8080</port>
</proxy>
However, as the proxy configuration is set globaly, I don't have access to the parameters (user, password, etc.).
Is there any way, to get Maven to using the global proxy, as NetBeans already does, without asking the admin?

Building a Docker-Image with maven and spring-boot on Windows

I'm trying to learn how to use maven, spring-boot and docker to create a web-application. I'm following this guide:
https://spring.io/guides/gs/spring-boot-docker/
I managed to build the maven project as such that localhost, says "Hello Docker World".
Then I copied the Dockerfile and added the extra property and plugin.
<properties>
<java.version>1.8</java.version>
<docker.image.prefix>springio</docker.image.prefix>
</properties>
...
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>com.spotify</groupId>
<artifactId>dockerfile-maven-plugin</artifactId>
<version>1.3.6</version>
<configuration>
<repository>${docker.image.prefix}/${project.artifactId}</repository>
<buildArgs>
<JAR_FILE>target/${project.build.finalName}.jar</JAR_FILE>
</buildArgs>
</configuration>
</plugin>
</plugins>
</build>
When executing mvn -N io.takeri:maven:wrapper to add the maven wrapper I received an error:
Error resolving version for plugin 'io.takeri:maven from the repositories[...]: Plugin not found in any plugin repository -> [Help 1]
As the command above has already worked on a different attempt (without docker) I checked the Help 1-link
https://cwiki.apache.org//confluence/display/maven/pluginresolutionexception
and added the same plugin-repository to the pom.xml as in the other project were it worked.
This proved to be ineffetive.
Executing the Project without the wrapper (mvn install dockerfile:build)
gives a MojoExecutionException followed by a long Error-Trace
and the
error: Failed to execute goal com.spotify:dockerfile-maven-plugin:1.3.6:build
(default.cli) on project ...: Could not build image:
java.util.concurrent.ExecutionException:
com.spotify.docker.client.shader.javax.ws.rs.ProcessingException:
org.apache.http.conn.HttpHostConnectException: Connect to localhost:2375
[localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused:
connect
How can I resolve this issue?
Note1: I'm new to Maven AND Spring-Boot AND Docker AND Stackoverflow, please let me know how I can improve this post or learn more about them.
Note2: I'm running Windows 10, and was planning on using Virtual Toolbox for Windows and successfully executed this guide https://docs.docker.com/get-started/part2/

I wonder what repositories you refer to? Both the takari plugin and spotify plugin are available in maven central, so no repositories should need to be configured in your pom. Or did you add them to your settings.xml? Could you try to simply remove repositories from your project?
Maven distinguishes dependencies and plugins. So you have sources (repositories to download them from) for both, meaning repositories and pluginRepositories. Nowadays companies will use a mirror/proxy like nexus or artifactory, so the difference is not directly visible - you only configure the mirror and point all repositories there.
So to use plugins there must be a pluginRepository configured that contains that plugin. See settings.xml docs.
Since all you need is in maven central the default config should just work without any more to do. So just remove all repositories from your pom.xml or settings.xml
The docker error you get seems not to be related to maven or the plugin, it simply cannot communicate with your docker host. Maybe to port is wrong or you are running a docker version not compatible with the plugin or it was not running? Docker for Windows might require you to expose the daemon without TLS.
Hope any of this is of some help :)

I had same issue. HttpHostConnectException You must run docker deamon on your machine.

Maybe you could configure environment variables.

Deploying release jar error -Return code is: 400, ReasonPhrase: Bad Request [duplicate]

Im' getting an error when deploying an artifact in my own repository in a Nexus server: "Failed to deploy artifacts: Could not transfer artifact" "Failed to transfer file http:///my_artifact. Return code is: 400"
I have Nexus running with one custom repository my_repo with the next maven local configuration:
settings.xml
<server>
<id>my_repo</id>
<username>user</username>
<password>pass</password>
</server>
...
<mirror>
<id>my_repo</id>
<name>Repo Mirror</name>
<url><my_url_to_my_repo></url>
<mirrorOf>*</mirrorOf>
</mirror>
user has permissions to create/read/write into my_repo -
pom.xml
<distributionManagement>
<repository>
<id>my_repo</id>
<name>my_repo</name>
<url><my_url_to_my_repo></url>
<layout>default</layout>
</repository>
<snapshotRepository>
<id>snapshots</id>
<name>Snapshots</name>
<url><my_url_to_my_snapshot_repo></url>
</snapshotRepository>
</distributionManagement>
and then I execute
mvn deploy
and get the error. Any idea?

A couple things I can think of:
user credentials are wrong
url to server is wrong
user does not have access to the deployment repository
user does not have access to the specific repository target
artifact is already deployed with that version if it is a release (not -SNAPSHOT version)
the repository is not suitable for deployment of the respective artifact (e.g. release repo for snapshot version, proxy repo or group instead of a hosted repository)
Check those and if you still run into trouble provide more details here.

Just to create a separate answer. The answer is actually found in a comment for the accepted answer.
Try changing the version of your artefact to end with -SNAPSHOT.

400 Bad Request will be returned if you attempt to:
Deploy a snapshot artifact (or version) ending in -SNAPSHOT to a release repository
Deploy a release artifact (version not ending in -SNAPSHOT) to a snapshot repository
Deploy the same version of a release artifact more than once to a release repository

Cause of problem for me was -source.jars was getting uploaded twice (with maven-source-plugin) as mentioned as one of the cause in accepted answer. Redirecting to answer that I referred:
Maven release plugin fails : source artifacts getting deployed twice

In the rare event that you need to redeploy the SAME STABLE artifact to Nexus, it will fail by default. If you then delete the artifact from Nexus (via the web interface) for the purpose of deploying it again, the deploy will still fail, since just removing the e.g. jar or pom does not clear other files still laying around in the directory. You need to log onto the box and delete the directory in its entirety.

I had this exact problem today and the problem was that the version I was trying to release:perform was already in the Nexus repo.
In my case this was likely due to a network disconnect during an earlier invocation of release:perform. Even though I lost my connection, it appears the release succeeded.

I had the same problem today with the addition "Return code is: 400, ReasonPhrase: Bad Request." which turned out to be the "artifact is already deployed with that version if it is a release" problem from answer above enter link description here
One solution not mentioned yet is to configure Nexus to allow redeployment into a Release repository. Maybe not a best practice, because this is set for a reason, you nevertheless could go to "Access Settings" in your Nexus repositories´ "Configuration"-Tab and set the "Deployment Policy" to "Allow Redeploy".

in the parent pom application==> Version put the tag as follows: x.x.x-SNAPSHOT
example :0.0.1-SNAPSHOT
"-SNAPSHOT" : is very important

Ensure that not exists already (artifact and version) in nexus (as release). In that case return Bad Request.

For 400 error, check the repository "Deployment policy" usually its "Disable redeploy". Most of the time your library version is already there that is why you received a message "Could not PUT put 'https://yoururl/some.jar'. Received status code 400 from server: Repository does not allow updating assets: "your repository name"
So, you have a few options to resolve this.
1- allow redeploy
2- delete the version from your repository which you are trying to upload
3- change the version number

If any of the above answers worked out, You can create new artifact directly from the admin side of (NEXUS Screen shot attached below).
Login to nexus UI http://YOUR_URL:8081/nexus( username: admin
default password: admin123 )
Click repositories on the left side then click the repo, For eg: click release.
Choose artifact Upload (last tab).
Choose GAV definition as GAV Param- Then enter your groupid , artifact id and version .
Choose Jar file.
Click upload artifact.
Thats it !
Now you will be able to add the corrsponding in your project.(screenshot below)

This can also happen if you have a naming policy around version, prohibiting the version# you are trying to deploy. In my case I was trying to upload a version (to release repo) 2.0.1 but later found out that our nexus configuration doesn't allow anything other than whole number for releases.
I tried later with version 2 and deployed it successfully.
The error message definitely dosen't help:
Return code is: 400, ReasonPhrase: Repository does not allow updating assets: maven-releases-xxx. -> [Help 1]
A better message could have been version 2.0.1 violates naming policy

I was getting the same 400 response status, and the issue was resolved by adding -Dresume=false.
mvn -B release:prepare release:perform -Dresume=false
In my case, the release:prepare target was being skipped and the following message was logged in the output.
[INFO] Release preparation already completed. You can now continue with release:perform, or start again using the -Dresume=false flag
I suspect that I may have made changes in the pom.xml that required forcing the release:prepare to run again before running release:perform.

Server id should match with the repository id of maven settings.xml

What worked for me was disabling the ReleaseProfile that comes with the release plugin and skipping the deployment in the deploy plugin
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<configuration>
<tagNameFormat>v#{project.version}</tagNameFormat
<autoVersionSubmodules>true</autoVersionSubmodules>
<releaseProfiles>releases</releaseProfiles>
<useReleaseProfile>false</useReleaseProfile>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-deploy-plugin</artifactId>
<configuration>
<skip>true</skip>
</configuration>
</plugin>
Use mvn help:effective-pom

Watch our for your CI doing a deploy after your release:prepare step. For us it was recent introduction of the official Bitbucket Server Integration plugin in Jenkins that was instantly firing on the push from release:prepare.
The fix was to add a step in the plugin for "Polling ignores commits with certain messages" with: ^(?s)\[maven-release-plugin\].* (from https://stackoverflow.com/a/32371336/1399659)

How to configure a proxy server for both HTTP and HTTPS in Maven's settings.xml?

I'm using Maven 3.1.1 behind a proxy server. The same proxy handles both HTTP and HTTPS traffic.
I can't seem to tell maven using settings.xml to use both protocols. It seems to me that it is only possible to have one active proxy, as whichever active proxy is defined first is used, and subsequent 'active' proxy definitions are ignored. This is my settings.xml:
<proxies>
<proxy>
<id>myhttpproxy</id>
<active>true</active>
<protocol>http</protocol>
<host>192.168.1.2</host>
<port>3128</port>
<nonProxyHosts>localhost</nonProxyHosts>
</proxy>
<proxy>
<id>myhttpsproxy</id>
<active>true</active>
<protocol>https</protocol>
<host>192.168.1.2</host>
<port>3128</port>
<nonProxyHosts>localhost</nonProxyHosts>
</proxy>
</proxies>
Is it possible to configure a proxy for both HTTP and HTTPS in maven's settings.xml? I'm aware that I could workaround this by passing Java system properties to the maven invocation such as:
-Dhttps.proxyHost=192.168.1.2 -Dhttps.proxyPort=3128
but surely this must be possible from within settings.xml?
Maven bugs raised such as MNG-2305 and MNG-4394 suggest this issue is resolved, but I am not convinced.
Alternatively, is there a "proxy proxy" I could run locally that I could point maven to? The "proxy proxy" would route http/https accordingly. Even so, I would still need to define two active proxy definitions in settings.xml for Maven to direct both types of traffic.

Maven proxy from settings.xml is used for both http and https, so you just need to define one proxy server and it will be used for both, you just need to leave only one proxy tag, like this:
<proxies>
<proxy>
<id>myhttpproxy</id>
<active>true</active>
<protocol>http</protocol>
<host>192.168.1.2</host>
<port>3128</port>
<nonProxyHosts>localhost</nonProxyHosts>
</proxy>
</proxies>
The protocol above is the protocol of the proxy server, not the proxied request.

Update 2022-01: a more up-to-date answer/solution for the current tech-stack (Eclipse 4.17 / 2020-09) can be found here
(old: 4.6 / 2017)
It works without the extra ...<id>httpsproxy</id>... entry (as #Krzysztof Krasoń mentioned) and with it (as the asker stated).
The problem for us was, that the Eclipse->Maven->User Settings->[x] Update Settings was obviously not working at all and to test certain things Eclipse->Maven->[x] Download repository index updates on startup must be checked (e.g. Maven Repositories View->Global Repositories->central->Update Index). And most of all:
Eclipse must be restarted after every settings.xml update! :-/
I guess it's a bug or reload/caching issue.
We successfully tested it with
Kepler (4.3) and Neon (4.6)
and their embedded Maven versions (3.2.1 / 3.3.9) as well as an external
3.3.3
with http:// and https:// URLs

I solved the problem with updating the maven version, or in other words not using the embedded eclipse maven version, but external version 3.3.9.

My tests with Eclipse Maven show that the protocol in settings.xml is referring to the protocol of the proxy server, not the protocol of the URL request. It also shows that Maven only uses the first active proxy server listed, and ignores the rest.
Here's my evidence:
1. The documentation says that
active: true if this proxy is active. This is useful for declaring a set of proxies, but only one may be active at a time.
protocol, host, port: The protocol://host:port of the proxy, separated into discrete elements."
2. The source code is even clearer:
/**
* Get the protocol of the proxy server.
* #return the protocol of the proxy server
*/
public String getProtocol()
{
return protocol;
}
3. Real world tests (using Eclipse Maven):
a. 1st proxy is a bogus ftp, 2nd is real http, 3rd is real https. Result: FAIL.
If the protocol were for the URL request, then Maven would've looked up the real http/https proxies and worked perfectly fine. Instead, it used the 1st proxy even though it was "ftp", and failed.
<proxies>
<proxy>
<id>bogus_ftp</id>
<active>true</active>
<protocol>ftp</protocol>
<port>123</port>
<host>bogus.proxy.com</host>
</proxy>
<proxy>
<id>real_http</id>
<active>true</active>
<protocol>http</protocol>
<port>123</port>
<host>real.proxy.com</host>
</proxy>
<proxy>
<id>real_https</id>
<active>true</active>
<protocol>https</protocol>
<port>123</port>
<host>real.proxy.com</host>
</proxy>
</proxies>
b. 1st proxy is real http, 2nd is bogus https. Result: SUCCESS.
This shows that it only used the 1st proxy. Otherwise, it would have used the 2nd proxy for https requests, hit the bogus proxy server, and failed.
<proxies>
<proxy>
<id>real_http</id>
<active>true</active>
<protocol>http</protocol>
<port>123</port>
<host>real.proxy.com</host>
</proxy>
<proxy>
<id>bogus_https</id>
<active>true</active>
<protocol>https</protocol>
<port>123</port>
<host>bogus.proxy.com</host>
</proxy>
</proxies>
c. Both are http, but 1st proxy is bogus, 2nd is real. Result: FAIL.
This shows that maven doesn't use multiple proxies, even for the same protocol. Otherwise, it would have tried the 2nd real proxy and succeeded.
<proxies>
<proxy>
<id>bogus_http</id>
<active>true</active>
<protocol>http</protocol>
<port>123</port>
<host>bogus.proxy.com</host>
</proxy>
<proxy>
<id>real_http</id>
<active>true</active>
<protocol>http</protocol>
<port>123</port>
<host>real.proxy.com</host>
</proxy>
</proxies>

For Eclipse 4.17 (2020-09) with M2E 1.16.1 (and the focus it should especially work there!) and Maven 3.3.3 (external) or 3.6.3 (embedded) (and likely similar combinations/versions) it works for mixed http://... and https://... repo URLs with the following setup (other than in the past):
e.g. to make it work for settings.xml or pom.xml:
<url> https://repo.maven.apache.org/maven2 </url>
<url> http://my-local-repo/repository/rep1 </url>
<url> http://my-local-sonatype-nexus-repo-manager-oss-v3/repository/rep2 </url>
you need:
two entries in your <usr-home>/.m2/settings.xml if some repos have http:// and some https:// URLs (unfortunately not like maybe stated in docs or in older Maven or m2e versions/combinations)
<proxy>
<id>http</id>
<active>true</active>
<protocol>http</protocol>
<port>8080</port>
<host>some-proxy.com</host>
</proxy>
<proxy>
<id>https</id> <!-- important!: different id than above! -->
<active>true</active>
<protocol>https</protocol>
<port>8080</port>
<host>some-proxy.com</host>
</proxy>
additionally the Eclipse M2E plugin has the problem to not sync at all if the
Window -> Preferences -> Maven -> [x] Download repository index updates on startup is not enabled
(=> thus one could think of it as: "[x] Enable repository index updates (additionally on startup)")
furthermore some repos, e.g. the known Sonatype's Nexus Repository Manager v3 (at least 3.2), do not support indexing out-of-the-box (do not get confused by feature request NEXUS-17279) and thus one has at least two options:
set up index generation jobs for desired/unindexed repos
(Repo Admin UI -> Config -> Tasks -> Create Task -> Maven - Publish Maven Indexer files ...)
in M2E: Minimum Index Enabled should suffice (may take 20 min to index for central)
disable indexing for such repos in the Maven Repository view (Eclipse workspace wide)
right click those repos and select Index Details Disabled
(should become grayed out)
to check if some repo supports indexing (whether by config or design) you could check if the file <repo-base-url>/repX/.index/nexus-maven-repository-index.properties exists
e.g. https://repo.maven.apache.org/maven2/.index/nexus-maven-repository-index.properties
a list of free/commercial repo managers is provided on the Apache Maven Project website, where those open source ones support it (last checked 2022-02-10):
Apache Archiva
JFrog Artifactory Open Source
Sonatype Nexus Repository Manager v2
to be sure to not run into caching or crash problems you should restart Eclipse (e.g. with -clean option) in case something does not work right away after the above setup
Do not get confused: we experienced that the servers UI search (Nexus Manager) did not always display all available matches (but the M2E client did), e.g. "groovy-all" did only return some 2.* versions whereas some 3.* were in fact also available.
(Task jobs to repair the browse/search indizes did not help it)
Of course without indexing one would loose the ability to search within repo artifacts but the direct download should always work nevertheless.
e.g. via pom.xml -> right click -> Maven -> Add Dependency -> Enter groupId, artifactId ...
if you enter groovy in this generic search field there should be quite some suggestions if it works, "artifactId cannot be empty" or "groupId cannot be empty" warnings can be ignored (and any content in both will be ignored then):
if it still does not work, maybe Window -> Show view -> Maven Repositories -> -> Full Index Enabled must be checked (may take a while to complete)
(Eclipse restart not necessary)

My workplace's proxy is preventing me from using Maven

I work in the public sector so my workplace controls internet access pretty strictly. I've tried configuring the settings.xml file that M2Eclipse reads to no avail. It may be simple user error in my case, but I'd like to explore other options anyways just in case that it isn't.
I was looking at installing a local Nexus repository as I can get around the proxy for some programs (just not Maven in this case), but as of right now I don't even have admin privileges yet to try that solution out.
I suppose that I could also initialise the project on my own VPS, push the project to a git repository and then pull in the project on my work machine as well.
Should I just give up and add the required JARs to the project build path manually?
Any help would be much appreciated!

Cough cough not that my IT guy would appreciate me telling you this, but with the right configuration you can generally fool most proxies into letting you through.
First you have to configure your maven http proxy in settings.xml
<settings>
.
.
<proxies>
<proxy>
<id>example-proxy</id>
<active>true</active>
<protocol>http</protocol>
<host>proxy.example.com</host>
<port>8080</port>
<username>proxyuser</username>
<password>somepassword</password>
<nonProxyHosts>www.google.com|*.example.com</nonProxyHosts>
</proxy>
</proxies>
.
.
</settings>
Then you have to modify your User-Agent:
<server>
<id>archiva.localhost</id>
<configuration>
<httpHeaders>
<property>
<name>User-Agent</name>
<value>Internal-Build-System/1.0</value>
</property>
</httpHeaders>
</configuration>
</server>
So for example, if your organization only allows a certain version of internet explorer through the proxy, this is how you lie and claim that maven is that version of internet explorer so it won't bother you.
If this doesn't work because they fundamentally block the sites you need to pull JARs from, then you can get even tricker; yes it involves a VPS. One option would be to use git as you say.
Another option (IT guys hate this, do so at your own risk, as whatever your local policy is this probably violates it) is to set up your VPS as an HTTP proxy. You might set up something like Squid on your VPS, and then set up an SSH tunnel from your work machine to the VPS which connects to your HTTP proxy. So the way this would work is that your work machine would use an HTTP proxy that was a local port (say localhost:8080). That local port would connect to an SSH tunnel across some network-acceptable port (e.g. 80) to your VPS. Once the traffic gets there, your VPS is your HTTP proxy and your organization's proxy has been bypassed.
That would fail if your IT department has deep packet inspection set up, or bans the IP range of your VPS, or some other combination. But the bottom line is that if they let you pass network packets at all, they can do all sorts of things to make your life difficult, but if you are clever they probably can't stop you from setting up your own proxy and bypassing most/all of their infrastructure.

create settings.xml file under <your_home_folder>/.m2 folder. (settings.xml file never get create automatically at this location, So you can copy this file from <maven_install_dir>/conf/ folder to <your_home_folder>/.m2 and override)
Now edit this file at <your_home_folder>/.m2/settings.xml and un-comment the following porting in settings.xml file and configure with your proxy settings.
<proxies>
<proxy>
<id>optional</id>
<active>true</active>
<protocol>http</protocol>
<username>proxyuser</username>
<password>proxypass</password>
<host>proxy.host.net</host>
<port>80</port>
<nonProxyHosts>local.net|some.host.com</nonProxyHosts>
</proxy>
Now re-run your maven job.