Annoying password resets in Archiva

Our dev shop at work had very little in the way of Continuous Integration (CI) infrastructure.  I’ve been praising the benefits of the CI gospel since I arrived here, but paradigm shifts are never easy.

Since my development is isolated from The Corp’s standard procedures, I began using as much CI best practices as possible.  I wanted to start with something that would be simple for other, non-CI developers to adopt, so I started with jar file management.  After reviewing a few options, it seemed like Archiva would fit the trick.

After a few weeks of using this on my own, it did not take long for other developers to see the benefit of using Archiva, and I was more than willing to give them access and help.  I had my own user, and I gave them a username/password combo that they shared amongst all of their developers.

Every so often these usernames’ passwords would expire, and it was a very annoying process to reset them.  After much time googling the issue, I was able to find the documentation that would prevent me from having to reset the passwords on a regular basis:

Just add the following entries to your <ARCHIVA_HOME>/apps/archiva/WEB-INF/classes/org/apache/maven/archiva/


Hopefully this will help to remove me as the bottle neck for any Archiva related issues.

Archiva and Remote Repositories

My current client wants to move more and more towards a DevOps paradigm, which includes CI (Continuous Integration) tools. Since they have almost 200 apps across 50 JVMs, most of which were written using IBM’s RAD IDE well before the first dot-com bust, we elected to use an Ant with Ivy approach for these apps.

The newer apps I’m working on are Maven based, so we started by connecting these up to an Archiva jar repository first as a proof of concept, and now we need to integrate the older apps to use Ant, Ivy, and Archiva.

We ran into a couple of issues getting our local machines connected to remote repositories through Archiva. After much troubleshooting and reading Archiva’s docs, our mistake was pretty obvious: we were only connecting to the internal portion of Archiva.

We confirmed that the issue was Archiva by removing the info from Maven’s settings.xml that pointed to the Archiva instance, and having our local machines connect directly to the remote repository by including the info in the pom.xml.

The error we received when connecting to our Archiva instance was:

[ERROR] Failed to execute goal on project RandomStuff: Could not resolve dependencies for project currentclient:RandomStuff:jar:0.0.1-SNAPSHOT: Failure to find com.vaadin.addons:filteringtable:jar:0.9.4.v7 in was cached in the local repository, resolution will not be reattempted until the update interval of has elapsed or updates are forced -> [Help 1]

[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1]

We were able to grab certain Apache related jars using Archiva, but they were all configured as internal repositories. The new jars were failing because the remote repositories were not being recognized.

After a few attempts at connecting Repository Proxies, it dawned on us to create a Group Repository, which provided us with one URL that tells Archiva to look at both internal and external URLs.