In the previous post, we discussed how to install the JAR file to the locally .m2 repository.
In this post let us proceed with the remaining options.
Adding to the Project as a System-Scoped file
Consider this is 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 even 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 can be used as a short term fix and doesn't scale.
Adding the 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 need 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 quick hack for getting things working. But this doesn't scale or help to share the jar with other people.
Using a repository management tool like Nexus Or Archiva.
When we follow the option1 of installing the dependency jar directly to the local .m2 repository, it has 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 need 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 of using a repository management system. Main advantages are,
Faster Builds. Dependencies are cached locally in the centralised 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 the 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.
Let us continue to explore how we can publish the dependency to maven central repository in the next post.
Thank you for reading!!!