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

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.

Answer 2

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 3

I have a tendency to prefix the groupId with my own usual groupId. This makes it absolutely clear that it's something I've uploaded, just in case it leaks out to the world at large.

Answer 4

You might be in luck: Google has their own Maven repo for their projects. See this page: Instructions

I had a few Jar files that were propietary, so I had to load them on each workstation (we don't have a company shared repo yet). I put them in the source code tree in a /lib directory (not always a good idea), and added a small .BAT file (or .sh script) that contained the mvn install-file commands to load my local machine's repo the first time I build. If I ever have to update these jars, I'll update the "load.bat" file also, and just rerun it. In my circumstance, I don't expect that to happen more than once a year, maybe less.

Answer 5

Many sourceforge projects use the project's name in the groupid, eg:

GroupId net.sf.json-lib ArtifactId json-lib

This might be appropriate in the google example, as there are a lot of google artifacts.

Remember that you can use a classifer tag to differentiate between two jars at the same version but built for different purposes eg different JVMs.