Finding the Artifact ID of a Java Library

To build one’s Java applications with Maven, one has to at first find the group ID, the artifact ID, and the version number that together identify each of the Java libraries (artifacts, in Maven’s term) used by each of the Java applications. One also has to find where (i.e. a Maven repository) the artifacts reside. Fortunately the Maven Central Repository contains almost all popular open source Java libraries. And it is very easy to find the artifact ID, the group ID, and the version number of a Java library in that repository through The Search Engine for Maven Central.

For example, I was developing a Java application that used the StringTemplate Java template engine created by Terence Parr. The StringTemplate website told me that the latest version of StringTemplate then was 4.0.3. The website also said that I would need to download two jar files, ST-4.X.jar and antlr-complete.jar, to my classpath. That is, however, not the way with Maven. So I visited The Search Engine for Maven Central, and searched “StringTemplate”. The search engine found about seven artifacts (i.e. Java libraries) in the repository. One has the group ID “org.antlr”,  the artifact ID “stringtemplate, and the  latest version number 4.02. It is what I need. So I added the following fragment into my POM file:

<dependency>

    <groupId>org.antlr</groupId>

    <artifactId>stringtemplate</artifactId>

    <version>4.0.2</version>

</dependency>

It works! Since my application does not directly use Antlr. I do not have to do anything about it. Obviously StringTemplate uses Antlr but Maven will handle it automatically. With the Advanced Search feature of the The Search Engine for Maven Central, one can even search by Java class names.

There is an alternative Maven repository search engine at http://mvnrepository.com/. It works pretty well too. When I cannot find what I need using The Search Engine for Maven Central, I will try MVNRepository. Often it helps.

Background

Most Java applications use Java libraries. Usually one has to download each Java library to the same computer where the JVM runs, and to place the library file (usually a .jar file) on the classpath of the JVM. If one Java library uses other Java libraries, one has to find out what they are and from where one can get them, and download them to the classpath of the JVM; and repeat it recursively. That is quit a headache. In addition, when one deploys that Java application to another computer, one has to repeat all the works to make the libraries available on that computer. To do so, one has to keep well the knowledge of the dependency tree somewhere in an ad hoc manner.

Maven helps by explicitly keeping direct dependencies on other libraries in the Project Object Model (POM file) and handling indirect dependency automatically. In Maven’s term, a Java library is an artifact, and an artifact is usually identified by a group ID, an artifact ID, and a version number. For more information about Maven, check out the Apache Maven website, and the (free) Sonatype Maven Books.