Best practices for installing 3rd party libraries into your hosted Maven repository?

Question

Let's say that you have a project which is using a 3rd party library, such as Google's Analytics Data API (gdata), which does not appear to be currently deployed into any well-known or popular Maven public repositories/indexes. This isn't much of a problem, as I can just deploy the artifact into my local hosted Nexus repository.

But, are there any best practices in the Maven community for how I should name this library's "coordinates" in my POM, since a standard is not already set in public repositories for it?

For example, should I refer to it in my POM as

<dependency>
    <groupId>com.google</groupId>
    <artifactId>gdata-analytics</artifactId>
    <version>1.0</version>
</dependency>

or is there some better / more standard way for me to come up with the artifactId?

(And, why the heck wouldn't a provider of a few dozen libraries such as Google take some effort to get them hosted into the mainstream public Maven repositories/indexes? Wouldn't this make it easier for people to use them and thus drive up adoption?)

Answer 1

What you've done is pretty reasonable. A few extra points:

• When Maven obtains an artifact from Nexus, the artifact is named as artifactId-version. GroupId is annoyingly omitted. So, when the artifact is moved around (say, copied into WEB-INF/lib in a web app), your jar file will read "gdata-analytics-1.0". That's usually not a problem. However, if the artifact name is very common, like "util", you may want to include group information inside the artifactId, such as using groupId of "com.google" and an artifactId of "com.google.gdata-analytics". Yes, the repitition is annoying, but it yields maximum clarity on the file system and in searches. I've actually had a problem where two different groupIds both had a "core-1.0" jar, and one overwrote the other when being copied into the lib directory at build time.

• I second MattK's suggestion of aligning your Maven versionId with whatever version the artifact is commonly known by.

• If you follow Dominic's advice of prefixing the groupId with your own company name (eg acme), it may make it easier to take advantage of Nexus' routing feature. It will ensure that requests for internal artifacts aren't propagated out to Maven Central and end up in their logs (which may be important if your groupId is "acme.secret.project"!

Answer 2

I've been using Maven for about a year and have never run across a "standard" naming convention. I usually do exactly what you're doing, although I try to make the version number as close to the "real" version number as possible, just to avoid confusion in case I deploy multiple versions.