Maven. What to do with "homeless" jars?

Question

I have some proprietary.jar that I need to include in my project, but I don't wish to install it to the local repository.

What I did initially was to put the jar into version control in my project's lib/ folder, and then specify the Maven dependency as:

<!-- LOCAL DEPENDENCY -->
<dependency>
    <groupId>topsecret</groupId>
    <artifactId>proprietary</artifactId>
    <version>0.0.1</version>
    <scope>system</scope>
    <systemPath>${basedir}/lib/java/proprietary.jar</systemPath>
</dependency>

However, this becomes a big problem when my project becomes someone else's dependency. Maven will not be able to validate this POM because the path is not absolute.

What is the best way to overcome this problem?

Answer 1

I think the first question that needs to be answered is, why don't you want to install it in the local repository?

Maven follows a convention over configuration philosophy, so the more you fight "The Maven Way" the harder things are going to be for you. Unless you have a compelling reason for not installing the jar to the repository, that seems like the best solution to me.

If you are concerned about unauthorized users gaining access to the proprietary jar, there are alternative solutions such as using a repository manager like Nexus or Archiva.

Answer 2

For third party artefacts, it's cleanest and least pain free to create a separate repository dedicated to 3rd party artefacts. This makes it easy for anyone else in your team to build your project.

For example, I'm using Nexus (community editoin) to manage maven artefacts. When someone has a dependency on a 3rd party lib not in maven central, we add it to the third party repo. This allows everyone else to build without having to manually find and download the artefact.

Nexus supports various authentication strategies, including LDAP, so can guard sensitive artefacts from unauthorized use. Since moving to a repository manager, managing artefacts, particularly 3rd party artefacts has become a whole lot easier.

See

• Repository management with Nexus

PS: Another plus with Nexus is that you can create a "virtual" repository that is the composition of several repositories "flattened" into one. This puts an end to adding repositories to settings.xml or putting repositories in the project pom. You can dd your own repository, your 3rd party repository, and other popular repositories (central, apache, codehaus, jboss etc...) and set nexus up as a mirror. All requests then go through Nexus, speeding up the build and easing repository configuration.

Answer 3

I described in a previous answer how you can setup a file based repository and avoid the evil system scope when you can't use a corporate repository. Check it out.