Maven, Ant and sbt, how pull from a local SSL repo?

On the last post we covered how to put Apache Archiva behind HAProxy with SSL termination. Now we’re covering how to configure your tools of choice to query data from that repository.

Remember that we learned how to install a local Certificate Authority that would make your internal certificates work transparently? Bad news. Java doesn’t trust Windows Trusted Root store, it ships out with its own.

You’ll have to add your Certificate Authority to the Java store. These are AdoptOpenJDK 8 and 11 paths but it’s similar to most Java implementations.

Java CA store is present in a file called cacerts that you can find in the following places:

Now that you’ve pinpointed the location of the store we’re going back to openssl to convert your Certificate Authority certificate to the der format (Distinguished Encoding Rules) that Java prefers.

Keytool to the rescue!

Keytool comes with Java and is the default tool to deal with certificates Java-side.

Great! Keytool is working so let’s convert the certificate you have for your Certificate Authority ca_key.crt and convert it to der.

Note that AdoptOpenJDK default store password is: changeit.

Now that we have Java talking proper SSL to your artifacts repository, let’s configure your editor of choice.

Build Tools

For the following examples we’re going to assume that HAProxy is running on and on port 8888 dispatching to an Archiva backend. We’re also assuming that you’ve setup a repository in Archiva called acme-company-repo.


Maven pretty much takes care of everything by itself. You can set up repositories in pom.xml like this:

Assuming that the company repository will be password protected, at least for distribution, you should add credentials to your %HOMEPATH%\.m2\settings.xml:

That’s it. Maven will work fine out of the box.

Ant + Ivy2

As you probably know Apache Ant uses Apache Ivy to support repository management.

For Ivy we’re going to use 3 files, plus build.xml:

1) ivy.xml – list dependencies
2) build.xml – build file with “target” for ivy to get the dependencies
3) ivysettings.xml – define format on how dependencies are stored
4) %HOMEPATH%\.ivy2\ – to store password

ivy.xml – stores project dependencies:

build.xml – your project build file now has a resolve target to get the dependencies:

Notice that compile dependencies are downloaded to ./lib and testing dependencies to ./lib-test.
Also notice that we link to on your user to store login details to repository.

ivysettings.xml – defines how dependencies are stored in your internal repository:

%HOMEPATH%.ivy2\ – just stores your access code out of source control:

That’s all! While a bit more involved you can just do ant resolve and get all the dependencies for your project from the internal server repository.


Scala’s interactive build tool can also pickup from your internal repository.

build.sbt – where we store our build instructions:

Notice that the repository name must match Archiva’s realm. The rule of thumb is that archiva will place “Repository Archiva Managed ### Repository”.

%HOMEPATH%.sbt\credentials.sbt – we use a single file for credentials and then link different sbt versions to this file to make things more coupled together and password will be linked to repository and not to sbt version:

%HOMEPATH%.sbt\0.13\plugins\credentials.sbt – link the credentials from sbt 0.13 to common file:

You must create a credentials.sbt file on all sbt versions you’re using.

That’s all! You can start repo’ing away!

If this was helpful in any way, please leave a comment. Very interested to know how we may improve and what we’re going ok. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *