On Tuesday, I wrote a blog about How your build is leaking internal data and how you can prevent this using Nexus Routes. Our Engineering team chimed in on Tuesday and suggested that it would be a good time to introduce a valuable, undocumented debugging tool that you can use to gain some insight into how Nexus is resolving artifacts.
Try this in a browser that knows how to render JSON (like Google Chrome):
- Make a request for an artifact, let’s use Apache Tomcat 6.0.29 from http://repository.sonatype.org as an example. This artifact is available from this link: https://repository.sonatype.org/content/groups/forge/org/apache/tomcat/apache-tomcat/6.0.29/apache-tomcat-6.0.29-bundle.tar.gz
- Next, just add “?describe” to the end of the URL. Using https://repository.sonatype.org/content/groups/forge/org/apache/tomcat/apache-tomcat/6.0.29/apache-tomcat-6.0.29-bundle.tar.gz?describe
Adding the “describe” flag to the end of the request URL asks Nexus to return a JSON document that summarizes how Nexus resolved a particular artifact. The output of this “describe” flag has two main sections. A section detailing the request information and a section detailing the response information.
Here is the section that details the request. The information in this section is straightforward: remote IP address, User Agent, path requested. This section may come in useful to find out how a particular request registers in Nexus.
Here is the section that details the response along with all of the process that went into resolving an artifact and which repositories were consulted. You can use this information to make sure that your requests to a Repository Group are resolving artifacts against the right repositories. You can use this section to verify that your routes are effectively limiting the repositories that response to a specific GAV coordinate.