Overview
When switching projects there is a chance that you may
encounter an issue with your Maven pom.xml file in Eclipse.
This, if you are lucky, manifests as “Failed to authenticate
with Proxy” and if you are not as a simple red error at the top of the window
containing the pom.xml, which says “CoreException: Could not calculate build
plan: Plugin org.apache.maven.plugins:maven-compiler-plugin:3.1…” or
something similar.
The cause of this problem is mixed.
However the root-cause is the same … the IPL proxy.
Somewhere in all the project dependencies is one that is an https and that will trigger the proxy
& its infamous man in the middle attack.
Fortunately all the failure scenarios have the same cause
and are relatively easy to fix (once you know how).
How does this appear?
As an error on the POM.xml screen
The first way this may manifests is often when you update
your project immediately after opening a new Eclipse project.
You may get this error message:
There is a message telling you about “multiple problems”;
ignore this.
The dialogue behind shows the real reason, but you may not
see it for what it is.
Your POM.XML window also is decorated with an error:
Clicking it simply reveals more confusion and woe.
It will tell you that org.apache.maven.plugins:maven-compiler-plugin
has failed to resolve but when you check your Maven repository it is
there.
In fact when you run Maven from the command line there does
not seem to be a problem.
To make things worse there is a second possible error:
As an error within the POM.xml
Sometimes the error appears in the Project Explorer and as a
simple red cross next to lines of the POM.xml when viewing the source.
For example:
Or
What the @&%$ is going on?
What is happening?
So something is broken in Eclipse when it uses Maven, but
Maven is ok; therefore the issue is in Eclipse …. WRONG!
Actually the issue is with Maven because Eclipse is actually
attempting to do a “force update” of the project dependencies, plus its own
verification of other dependencies.
The issue is that the majority of the repositories are
accessed via http and minority are via HTTPS.
You may be operating within a corporate network with a proxy that needs to inspect all traffic. Therefore it performs a man-in-the-middle attack on all
HTTPS traffic and requires you to pass your login credentials to it so that you
can access the HTTPS sites. So the client (you) still sees HTTPs and the server still sees HTTPs, vut our listener can inspect everything.
This arrangement can upset JAVA when it notices the certification is one it does not trust.
What are the causes?
The four causes identified so far are:
- Your credentials, stored in the Maven settings, are wrong and need changing.
- You have changed your Java version and no longer are using a version that has the IPL certificate added to it.
- You are no longer using the specific maven settings that existed for a project;
- You no longer have valid user credentials settings in your profile to access the correct mirror.
Speak to your SysOps guys and have your creds checked.
How do I fix it?
Do not …
Firstly do not initially attempt to resolve it by altering
the Eclipse settings as this may make things worse.
The problem is with probably with Maven and not Eclipse.
This doesn’t mean that your copy of Eclipse is fully working
it simply isn’t responsible for this issue.
So…
Check your project from the command-line
It is possible that your project will build fine from the
command line.
mvn clean package
-DskipTests
If this works then move on to “Check which Maven installation Eclipse is using…”.
If not then as long as the error is not just a code build
error but is clearly a “can’t resolve dependency” issue, then the problem may
be with your repository & there may simply be a broken dependency.
So check it using:
mvn -U clean
package -DskipTests
This will force an update of the repository and download new
files.
If the project is broken still this doesn’t help move on to
“Clear your Maven Repository”.
It is possible that your repository is in a “broken” state
and will not update correctly because there is a library that is waiting to be
updated. Therefore your local repository is somehow mucked up for release jars
as opposed to snapshots (-U and --update-snapshots only update
snapshots), you can purge your local repo of all of its update flags. Open a
command prompt in your repository folder and then delete all the flags using:
forfiles
/m *.lastUpdated /s /c "cmd /c del @file"
Then try the “mvn -U
clean package –DskipTests” on your project.
If this doesn’t work try the following:
mvn
dependency:purge-local-repository
You should see all the dependencies maven needs as standards
downloading.
Now rebuild using “mvn -U
clean package –DskipTests”.
Failing that there is one nuclear option which is to totally
delete your repository and rebuild.
So when you have found out where your local repository is …
delete it; then rebuild.
There should be no issues at this point as maven should load
all its files via http.
So proceed to “Check which Maven installation Eclipse is
using…”.
One issue could be if you seeing, especially if your copy of
Eclipse is new, is you could be using the embedded copy of Maven that the M2E
plugin ships with.
If this is the case got to Windowà Preferencesà Mavenà Installations
and add your Maven installation as your active installation.
If you change it check your project … Close eclipse, delete
your maven local repository & re-open Eclipse & force an update of the
project.
If not fixed then check “Are you using the correct Maven settings
files?”.
On the screen Windowà Preferencesà Mavenà User
Settings;
They should be Global
Settings pointing to the folder where Maven is installed & User Settings should point to an .m2
folder in your user directory.
i.e.
If they are not the correct files (which can happen if this
is a new Eclipse install) update the paths.
Then … Close eclipse, delete your maven local repository &
re-open Eclipse & force an update of the project.
If not fixed then check “Is Eclipse using the same Java version?”.
It is possible that your maven install & your eclipse
install are using different Eclipse settings.
First check maven by running:
Which will give you something like this:
Now check in Eclipse.
The JVM in use can be found by looking in Helpà Aboutà Installation
Details, Configuration Tab which gives you:
If they don’t match; ensure your JAVA_HOME is set correctly and your PATH is picking up the correct Java install.
If this doesn’t fix the issue then we have to “Diagnose the Eclipse Issue.”.
At this point you should have a project which works on the
command-line but not in eclipse.
You should find that the project will build in Eclipse if
you click on the pom.xml file and use Run
Asà Maven Install. This is
because the project is being built using the same JVM as Eclipse and on the
Command-line.
However there is an error & the key issue here is:
The requested resource is on a https site and access to a
HTTPs site is blocked by the firewall.
It is possible to configure Maven to authenticate its self
with the proxy (see “A not authenticated with Proxy error”). However,
the correct methodology is described in the next section.
A secondary, problem here is not with the project
dependencies but with “Plugin Dependencies”. These are being read by the
Eclipse IDE.
At this point it is best to check whether the correct
repositories are being loaded into Eclipse.
This can be found by viewing the Maven repositories loaded
by Eclipse in its “Maven View” panel.
To get this view got to Windowà Show Viewà Other..
then select “Maven Repositories”.
If this is the case proceed to “Configure your profiles”.
In the example above the system is configured to look at the
internal mirror.
There should be settings for your project and they should be
established as your active profile.
This example uses generic settings with the example of using a
Sonatype Nexus server as the Mirror.
In your <home>/.m2/settings.xml file ensure that you
have a profile defined as follows:
<profile>
<id>Nexus</id>
<repositories>
<repository>
<id>Nexus-Maven-Public-Assets</id>
<name>Maven
Public Assets</name>
<url>http://example.com:8888/nexus/content/groups/public/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>Nexus-Plugins-Maven-Public-Assets</id>
<name>Maven
Public Assets</name>
<url>http://example.com:8888/nexus/content/groups/public/</url>
</pluginRepository>
</pluginRepositories>
</profile>
…
<activeProfiles>
<activeProfile>Nexus</activeProfile>
</activeProfiles>
In this example two repositories are added, both pointing at
a mirror of the Public code on the fictional example.com Nexus mirror. It is the second
repository that is the important one as it relates to the Plugins that are
failing to load in Eclipse.
This should fix all your Eclipse issues but if not proceed
to “Do you have a mirror set up in your
settings?”.
A mirror is
different to a repository. With Repositories you specify from which
locations you want to download certain artefacts,
such as dependencies and maven-plugins. Repositories can be declared inside a
project, which means that if you have your own custom repositories, those
sharing your project easily get the right settings out of the box. However, you
may want to use an alternative mirror for a particular repository without
changing the project files.
Why use a mirror
Some reasons to use a mirror are:
1. There
is a synchronized mirror on the internet that is geographically closer and
faster
2. You
want to replace a particular repository with your own internal repository which
you have greater control over.
3.
You want to run a repository manager to provide
a local cache to a mirror and need to use its URL instead
Within IPL we do have a mirror so an argument could be made
for using the mirror configuration.
One side of this argument is all traffic via Maven should go
via the mirror so it can be recorded and used to analyse the content of the
project.
The problem with this approach is it is very easy to set
them up to capture everything sooner than specific traffic.
The current methodology (also described here) is to mirror
everything using ‘*’, sooner than a specific mirror for a public site such as
‘central’. This would mean that your mirror has to hold everything.
So the counter proposal is to set up specific profiles or
add the mirror directly to the project in which was described in the previous
section.
Configure the mirror
The usage guide states:
“Specifies a repository mirror site to use instead of a
given repository. The repository that this mirror serves has an ID that matches
the mirrorOf element of this mirror. IDs are used for inheritance and direct
lookup purposes, and must be unique across the set of mirrors.”
It is advisable that the mirror settings are located in the
same settings file as the localRepository
settings. This is because files will have been copied to from the mirror to
the local repository and when the mirror changes it are these files that will
alter.
- <settings>
- ...
- <mirrors>
- <mirror>
- <id>UK</id>
- <name>UK Central</name>
- <url>http://uk.maven.org/maven2</url>
- <mirrorOf>central</mirrorOf>
- </mirror>
- </mirrors>
- ...
- </settings>
Where the mirrorOf
node is important in selecting what is drawn from the mirror.
In the above case all files are fetched.
You shouldn’t be stuck with this error if you have followed
the previous steps.
However if you are the two causes of an error like this:
1. Incorrect
proxy credentials;
2. An
issue with JAVA JVM.
Do
you have the correct proxy settings?
Within your maven settings you should have a proxy settings section that looks
something like this:
- <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>
Check the settings:
Is the password right!?
- The username must … must … start with MYDOMAIN\\ and not just be your account name or only have a single back-slash.
- It is vital to check that you don’t have more than one proxy profile with active=true;
- It is vital that the protocol=http and not https as it must match the protocol of the proxy not what is being served;
If you change anything save, and close Eclipse, delete your maven local repository & re-open Eclipse & force an update of the project.
Got proxy settings established but now it’s a ‘certification error’?
You just got an error that looks like this:
Whoa, what the heck is that?
Why would java not be able to connect to my internal
repository?
To make sense of the error and what it's actually
complaining about, it's necessary to understand a little bit about how SSL
works. The server in question — and any server which connecting to might result
in the error message above — is protected by HTTPS, which is HTTP with SSL
added on. SSL was designed to protect against a lot of different security
problems, one of the most complex of which is the man-in-the-middle attack. For
various reasons, internet traffic is particularly susceptible to active attacks
whereby a malicious party pretends to be the server you're trying to talk to
and intercepts your communications. To guard against this, SSL mandates (at the
risk of slightly oversimplifying) that the server present a certificate that
identifies it as the true bearer of the hostname you're trying to connect to;
maven.2xoffice.com in this case. Of course, in and of itself, this provision is
next to useless — after all, any attacker who can intercept your communications
and masquerade as the target server can just as easily forge a certificate
claiming to be the correct server.
As it turns out, this was a well-studied problem in
cryptography circles in the mid 90's when SSL was designed — the solution is a
Public Key Infrastructure (PKI). In this system, a handful of trusted parties
are authorized to digitally sign certificates — in effect, "vouching
for" the legitimacy of the bearer of the certificate. Such trusted parties
are called certificate authorities
With this brief background, the error message "unable to find valid certification path to
requested target" begins to makes some sense — what Java (by way of
Maven) is trying to tell you is that the server presented a certificate, and
the certificate did identify itself as the rightful bearer of the hostname
maven.2xoffice.com. Furthermore, the certificate was properly digitally signed
— unfortunately, not by a legitimate certificate authority.
So, what makes a certificate authority a
"legitimate" one? Every SSL-capable client has its own answer;
browsers, for example, have a list of trusted certificate authorities. They're
identified by their own certificates (more specifically, by the secure hash of
their certificate's contents). In Chrome, for instance, you can see a list of
trusted certificate authorities' certificates by going into Settings->Manage
Certificates and seeing a list of several trusted "root" certificates.
Any certificate signed by one of these roots will be
trusted; untrusted ones will result in a warning message.
Java, on the other hand, doesn't have a "Settings"
tab; instead, it has a setup folder. Specifically, $JRE_HOME/lib/security.
Here, there's a file named cacerts that lists all of the trusted root
certificate authorities. You can view this list using the keytool that comes
with the JDK.
This is where the version of Java in use with Eclipse really
starts to matter.
As long as your copy of Java has the IPL certificate &
Eclipse is pointing to the right JDK, it will work
.
Installing the IPL Certificate
- If you don’t have a copy of your company certificate, ask your sysOps guys & save it as certnew.cer;
- Go to your java_home\jre\lib\security folder;
- (Windows) Open admin command line there using 'cmd' and CTRL+SHIFT+ENTER
- Run keytool to import certificate:
..\..\bin\keytool -import -trustcacerts
-keystore cacerts -storepass changeit
-noprompt -alias corpCert -file path\to\certnew.cer
Now this particular
java JVM will have the Certificate.
This process needs
to be repeated for all your JVMs.
Uninstalling the IPL Certificate
Should there be an issue where the certificate is wrong or needs to be removed then the process is as follows:
- Go to your java_home\jre\lib\security folder;
- (Windows) Open admin command line there using 'cmd' and CTRL+SHIFT+ENTER
- Run keytool to delete certificate:
..\..\bin\keytool -delete -keystore cacerts
-storepass changeit -noprompt -alias corpCert
Testing the Corporate Certificate
Should want to test
whether the certificate is working then this class can be used to test it:
/**
* A Certificate test which checks for
HTTP/HTTPS access using the current JVM.
*/
package
com.example;
import
java.io.DataInputStream;
import
java.net.URL;
import
java.net.URLConnection;
public
class CheckCert {
private static final String PROXY_HOST =
"example.com";
private static final String PROXY_PORT =
"8888";
/**
* @param args
*/
public static void main(String[] args) {
System.out.println("JAVA
VERSION:\t"+System.getProperty("java.version"));
System.out.println("JAVA
HOME:\t"+System.getProperty("java.home"));
System.out.println("JAVA
RUNTIME:\t"
+System.getProperty("java.runtime.version"));
//
doConnect("http://example.com/");
System.out.println("USE HTTP");
doConnect("http://repo.maven.apache.org/maven2");
System.out.println("USE
HTTPS");
doConnect("https://repo.maven.apache.org/maven2");
System.out.println("USE HTTPS -
WITH PROXY SETTINGS");
setProxySettings();
doConnect("https://repo.maven.apache.org/maven2");
System.out.println("DONE.");
}
public static void setProxySettings() {
System.clearProperty("http.proxyHost");
System.setProperty("http.proxyHost",
PROXY_HOST);
System.setProperty("http.proxyPort", PROXY_PORT);
System.setProperty("https.proxyHost", PROXY_HOST);
System.setProperty("https.proxyPort", PROXY_PORT);
System.setProperty("java.net.useSystemProxies",
"true");
}
private static void doConnect(String
urlText) {
System.out.println("-------------------------------------------");
System.out.println("Connecting to
" + urlText);
try {
URL myURL = new URL(urlText);
URLConnection myURLConnection =
myURL.openConnection();
myURLConnection.setUseCaches(false);
myURLConnection.connect();
System.out.println("Connected
to " + myURLConnection);
DataInputStream di
= new
DataInputStream(myURLConnection.getInputStream());
int max = 100;
byte[] b = new byte[max];
if (-1 != di.read(b, 0, max)) {
System.out.println("DATA:\n"
+ new String(b));
}
} catch (Throwable ex) {
ex.printStackTrace();
System.err.flush();
}
System.out.println("-------------------------------------------");
}
}
You can use this
class to verify the JVM can access a HTTPS site as long as it is told to use the proxy.
