Maven's declarative behavior forces user to use managed artifacts and discourages the use of unmanaged/external/unmavenized artifacts/jars.
There are couple of workarounds to solve this problem. Some of the hacks have been described below.
Method 1 : Using 'system' scope
Maven provides scope called 'system' which expects absolute path. But using absolute path will makes build user specific which should not happen in automation tools. This can be avoided using ${basedir} variable. This variable provides the absolute path of current module and hence jar put in relative with the current module can be relatively accessed with ${basedir} variable.
Cons : In case of modularized project, if same jar is being used in multiple modules, this jar should be duplicated in all those modules. (You may get a thought that why can't we keep it in parent pom, but child modules cannot access parent's absolute path. Maven 3+ doesn't support accessing parent's properties from child module.)
Method 2 : Using file based repository
Cons : In case of modularized project, if same jar is being used in multiple modules, this jar should be installed in all modules' repo. (You may get a thought that why can't we keep it in parent pom, but child modules cannot access parent's absolute path. Maven 3+ doesn't support accessing parent's properties from child module.). Moreover this method adds unnecessary files and commits to version control's repository which is not desirable.
Method 3(Recommended):
Method 2 can be enhanced by applying a bit of intelligence using maven plugin capability. In the preceding method, external jar is being installed into file based repo which is going to be existed in version conrol's repo. Instead, if you can install jar into user's local repository as soon as user ran clean or compile then it will automatically be installed into user's local repository. Now this can be accessed using minimal pom. I advice to go by following steps.
Pros : This will be a cleaner way, even in case of modularized project. Dedicatedly one module can be allocated to install these jars and plugin. Rest of the modules will be ignorant of external jars and they will just use them as if they were fetched from repository.
There are couple of workarounds to solve this problem. Some of the hacks have been described below.
Method 1 : Using 'system' scope
Maven provides scope called 'system' which expects absolute path. But using absolute path will makes build user specific which should not happen in automation tools. This can be avoided using ${basedir} variable. This variable provides the absolute path of current module and hence jar put in relative with the current module can be relatively accessed with ${basedir} variable.
- Create a folder(say lib) and keep external jars into lib folder.
- These jars can be accessed as shown below.
<dependency>Pros : Easy to implement
<groupId>com.bala</groupId>
<artifactId>test-artifact</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/test-artifact.jar</systemPath>
</dependency>
Cons : In case of modularized project, if same jar is being used in multiple modules, this jar should be duplicated in all those modules. (You may get a thought that why can't we keep it in parent pom, but child modules cannot access parent's absolute path. Maven 3+ doesn't support accessing parent's properties from child module.)
Method 2 : Using file based repository
- Create a local repo(say lib and commit this lib along with the external jars, if you use version control).
- Identify all the external jars and install them using following command.
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<custom-group-id> -DartifactId=<custom-artifact-id> -Dversion=<custom-version> -DlocalRepositoryPath=<path-to-local-repo-folder>
- Specify file based local repository in your pom as shown below.
<repositories>
<repository>
<id>custom-repo-id</id>
<name>custom-repo-name</name>
<url>file:${basedir}/lib</url>
</repository>
</repositories>
- Now external dependencies can be used with the help of minimal pom in dependencies section.
<dependency>Pros : Better than using system scope.
<groupId>custom-group-id</groupId>
<artifactId>custom-artifact-id</artifactId>
<version>custom-version</version>
</dependency>
Cons : In case of modularized project, if same jar is being used in multiple modules, this jar should be installed in all modules' repo. (You may get a thought that why can't we keep it in parent pom, but child modules cannot access parent's absolute path. Maven 3+ doesn't support accessing parent's properties from child module.). Moreover this method adds unnecessary files and commits to version control's repository which is not desirable.
Method 3(Recommended):
Method 2 can be enhanced by applying a bit of intelligence using maven plugin capability. In the preceding method, external jar is being installed into file based repo which is going to be existed in version conrol's repo. Instead, if you can install jar into user's local repository as soon as user ran clean or compile then it will automatically be installed into user's local repository. Now this can be accessed using minimal pom. I advice to go by following steps.
- Create a folder(say lib) in the current project and keep all the jars into that folder. In case of modularized project, create a module, say external-jar-installer and copy lib folder along with the jars into the module. Make sure that these jars should be checked in.
- Now use maven maven install plugin and configure all the jars in clean phase as shown below.
- As soon as we run mvn clean, all the jars will be fetched from lib folder and be installed into user's local repo. Hence minmal pom will becom valid for the user whoever is executing rest of the the mvn commands.
Pros : This will be a cleaner way, even in case of modularized project. Dedicatedly one module can be allocated to install these jars and plugin. Rest of the modules will be ignorant of external jars and they will just use them as if they were fetched from repository.
