<iframe src="//www.googletagmanager.com/ns.html?id=GTM-TT8R4P" height="0" width="0" style="display:none;visibility:hidden">

Sonatype Blog

Stay updated on the latest news from the makers of Nexus

Joel Orlina

Recent Posts by Joel Orlina:

Browse Repos Easily with Updated Maven Central Search

We’ve rolled out an update to Maven Central Search that makes the tool easier to use and fixes a handful of minor bugs.

Enhancements

  • Browse quickly to artifact directories when you know the path. The new browser bar text box lets you browse the repository in Central Search in almost the same way you browse http://repo1.maven.org with your web browser. Just type a path into the browser bar text box and you’ll be taken right to the artifact directory.Accessing the browser bar is easy –select the edit icon (which looks like a pen) next to the repository path in the Browse view and the repository path will be replaced with the browser bartext box.
  • Classname search is more flexible. You can paste in a path to a source file (e.g., org/apache/coyote/ajp/AjpAprProcessor.java) or to a class file (e.g, org/apache/coyote/ajp/AjpAprProcessor.class), and Central Search will construct a fully-qualified classname search from it.
  • Multi-page results are easier to browse. When search results run longer than your browser window, you can navigate from page to page without scrolling back to the top of the page as was previously required.
  • Browse view performance is improved. Long pages in the Browse view of the repository are now cached. This improves responsiveness when viewing the root directory of the Browse view (as well as the org, com, and net directories)..

Maven Central Building Blocks

In my last post, I explained the REST-style API that underlies Maven Central's browser-based search UI. That API essentially comes "for free" with the main components on which Maven Central Search is built:

In this post, I will highlight those components and describe how they were used to implement Maven Central Search.

When we started the project, we looked at a couple of options for implementing search, including Solr and the existing Nexus search capability built directly on top of Apache Lucene. The Nexus approach initially seemed compelling as we clearly have significant experience with it and Nexus search even provides a REST API for full-text search that we could have leveraged. So, why did we end up choosing Solr when we could have simply re-used the search functionality in Nexus or even crafted a web UI backed by an instance of Nexus running on top of Central? Two reasons:

  • Flexibility -- We discovered early on during the design phase of Central Search that we needed changes to the schemas, fields, and even field contents in the Lucene indices being used by Nexus. Making those changes to the schemas would have required other changes within the Nexus codebase. With Solr, we could simply point our Solr installation against an existing index or even have Solr build a new index from scratch by adding documents through Solr's REST API. We could rapidly prototype schema changes (often in 1-2 lines of xml and not even requiring us to restart Solr) and see our updated search results almost immediately.
  • Scalability -- Solr bills itself as an "enterprise search platform." One of the enterprise features that attracted us to Solr was its built-in support for replication. As query load increases in the future, we can simply balance that load across hardware serving multiple copies of the same data. Solr's support for multiple indexes also leaves us a path open for sharding our index data, once it becomes so large as to be difficult to serve out of a single index on a single server.

You Don't Need A Browser to Use Maven Central

Since its release in January, the Maven Central website (http://search.maven.org) has provided Apache Maven users with: