Apache Archiva 1.3 release and what’s next

In the midst of a busy couple of weeks, I neglected to post about the Archiva 1.3 release that was announced recently (and on that topic, Continuum has posted a new beta release as well).

The Archiva release focused mostly on bugfixes (particularly for indexing and LDAP), but we decided it was worthy of a version bump after the addition of an upload audit logging feature and some decent performance improvements. It’s an easy upgrade for 1.2 users – if you keep your configuration separate, then just unzip the new version and start it up using the same environment variables as you would the previous version.

Archiva is also easy to try out if you already have a Maven repository – its primary storage is the filesystem in a Maven repository format, so you can point it at a copy and everything will be available straight away (gradually indexing resources for access through the UI in the background).

As for what’s next – while it’s still to be put to vote, I hope that the next version will be based on the work I started again last year and have had in mind since almost the beginning of the project. This focuses on two underlying aspects: the removal of the archiva database requirement and the transformation to be an extensible metadata repository.

I always refer to the database removal as “Back to the Future”, since it is similar to the design pre-1.0 where Lucene was used to store all of the information, however in this case I had the opportunity to learn from our experiences and build on a more appropriate foundation:

  • A central, extensible metadata model that allows storage of any different repository , artifact, or resource type;
  • Delegating repository requests, to better facilitate repository grouping and proxying when configured, and to allow metadata to be regenerated from the storage on the fly;
  • Decomposing functionality into plugins so that optional portions can be removed. Plugins operate on metadata, certain repository events and a few other extension points. This remains a work in progress, but the aim is to allow reducing the deployable application to as little as a simple maven proxy cache for your local machine with a very low footprint, and to make it easy and robust to write and use a combination of different plugins.

At the moment, these changes are all under the hood – apart from configuration there is no visible difference other than the number of bugs that got removed along the way! However, the decoupling will make way for easier development of new features and the opportunity for much needed advances in the UI.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s