Using maven in a Java project is great. It manages builds (as customized as you may need), executions, dependencies… In fact, dependencies is, in my opinion, the key feature of maven. Whenever a dependency is added to a project, maven will search for it at repositories, download it and store it, tagging versions.
Some weeks ago I had to get an old project without maven and make it work with it. Everything went right at first: I had only to search for the correct dependency on the repository and config my project to get it. But suddenly I found a jar that wasn’t available on the repository: it was a custom generated jar to include some fonts that were being used by Jasper on a pdf generation.
I had to get it working without adding the jar to the repository. I got some working solutions:
Adding a system dependency
<dependencies> <dependency> <groupId>groupId</groupId> <artifactId>artifactId</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>${basedir}/lib/xx.jar</systemPath> </dependency> </dependencies>
I wouldn’t do it. System scope was created to add dependencies that once where external libraries but now are packed into the JDK. Also, the Assembly plugin ignores this kind of dependencies and it doesn’t pack them with the others.
Creating a maven repo inside the project
The idea is to create a maven repo that runs on our own computer instead or a remote server. Every file needed would be on the version control system so every developer can build the project once it is downloaded.
Three steps are needed to accomplish this:
1. Add the local repository to the project pom:
<repositories> <repository> <id>my-local-repo</id> <url>file://${basedir}/my-repo</url> </repository> </repositories>
In this case the repository will be stored on a directory called “my-repo” and it will be located in the project root directory.
2. Install jar in the repository through install-plugin.
On maven 2.2:
mvn org.apache.maven.plugins:maven-install-plugin:2.3.:install-file \ -Dfile=<path-to-file> -DgroupId=<myGroup> \ -DartifactId=<myArtifactId> -Dversion=<myVersion> \ -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
On maven 2.3 and onwards:
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<myGroup> \ -DartifactId=<myArtifactId> -Dversion=<myVersion> \ -Dpackaging=<myPackaging> -DlocalRepositoryPath=<path>
There are several options to be filled on the command:
-
path-to-file
: the path to the file of the artifact to install. -
myGroup, myArtifactId, myVersion
: the group, artifact name and version of the artifact to install. -
myPackaging
: the packaging of the artifact (ie: jar). -
path
: the path to the local repo.
3. Add the dependency to the project as usual.
After running the command of the second step, several files will be created on the local repository (like pom and checksum files). This is the reason I don’t like this solution, I find it ugly with those files added to the VCS.
Installing the jar by using install-plugin
The idea is to store the jar into a project directory and install it into the m2repo directory (where all mvn dependencies are downloaded to) on build time. To get this working the dependency should be added to the repository1 as usual, and also add the plugin to the pom configuration:
<project>
<groupId>org.koshik.javabrains</groupId>
<artifactId>JarName</artifactId> (A fldernamed JarName was created)
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging> <name>JarName</name>
<url>http://maven.apache.org</url> <properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties> <build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-install-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<phase>initialize</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>myGroupId</groupId>
<artifactId>myArtifactId</artifactId>
<version>myVersion</version>
<packaging>jar</packaging>
<file>${basedir}/lib/xxx.jar</file>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build> <dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
This is the solution I decided to use on the project I was working on. It’s clean and it’ll work from the first moment a new developer downloads the project from the VCS(I mean the source code repository: SVN, GIT or whatever you use).