Installing Third-party JARs to a Maven Project — 2
In the previous post, we discussed how to install a third-party JAR file to the locally .m2 repository.
In this post let us proceed with the remaining options.
Adding third-party JAR to the Project as a System-Scoped file
Consider this as a short term strategy.
Download the .jar file and place it in the local file system folder (make sure the location of the .jar file is read/write accessible).
Include the .jar file directly to the maven project (without installing to the .m2 repository) as a dependency with “systemPath” parameter.
Please find the below example of adding the claim-manager jar file as a system-scoped file.
This approach and installing the third-party jar to the local .m2 location is only recommended to be used as a short term fix, as it is not scalable when sharing third-party jars across multiple developers. Each developer has to install the jar in the local system using either way.
Adding the third-party JAR as an IntelliJ Project Dependency
We can use this as a quick hack to install the third party jar to the IntelliJ Project bypassing maven.
- Open the Maven project in IntelliJ to which the jar needs to be added.
- Navigate to the “Open Module Settings” options by right-clicking the project.
- Navigate to the “Project Settings -> Libraries” section and add the dependency jar by + option to Java.
This is a quick hack for getting things working. But this doesn’t scale or help to share the jar with other people.
Hosting the third-party JAR in a repository management tool like Nexus Or Archiva.
All the options we discussed previously install the dependency jar to the local system, it has a drawback that each and every developer who works on the project has to do it on their local system. The third-party dependency jar file installed is not shared across the developers and systems. Also, there needs to be a proper mechanism of sharing these third party dependency jars with other developers.
When we move the project from one environment to the other (development, staging, pre-production, and production) we need to set up these third party jars again and again. This is a hindrance to the Continues Integration Continuous Delivery process (CI-CD process).
To overcome this challenge we have Repository Management tools, which we can install locally and maintain a shared cache of jar files across the organization.
Repository manager Or a binary repository manager is a, software tool designed to optimize the download and storage of binary files used and produced in software development.
It centralizes the management of all the binary artifacts generated and used by the organization to overcome the complexity arising from the diversity of binary artifact types, their position in the overall workflow and the dependencies between them.
There are several advantages to using a repository management system.
Main advantages are,
- Faster Builds.
Dependencies are cached locally in the centralized repository and thus eliminates the overhead of downloading from the public internet, thus reduces the build times. - Saving the bandwidth and controls the traffic.
Saves the overall bandwidth of the Organisation and eliminates excessive traffic to the maven central repository. - Predictability and Stability.
Since we are not relying on network connectivity. We can be stable and run builds even during network outages. - Ability to host third party artifacts.
Instead of hosting the jar locally, we can host it in the nexus repository which will be shared across developers and also maintained in the local cache.
There are several repository management tools available. Archiva and Nexus are two popular ones. You can download and install Archiva from here and Nexus from here.
References :
[1] https://archiva.apache.org/
[2] https://www.sonatype.com/product-nexus-repository
Let us continue to explore how we can publish the dependency to maven central repository in the next post.
Thank you for reading!!!
