Maven Dependecy JAR Configuration
Maven Dependecy JAR Configuration
Join the DZone community and get the full member experience.Join For Free
Atomist automates your software deliver experience. It's how modern teams deliver modern software.
When moving to Maven from other frameworks there are many questions arising, such as how to handle the configuration of a dependency artifact.What will happen, for example, when your dependency has some configuration files? The standard Maven way is to put all the configuration files under src/main/resources. That way, they will be located in the resulting jar in the right place, enabling your application to function properly.
But, what if you need those configuration files to be subject to change? In the case that they are located inside the jar, you are stuck with the default configuration without the ability to edit and change the module behavior.
I will offer here a way to enable such jar configuration usage.
Let us say we have a module, packed into Jar called jar-with-conf. This module contains a single class called ConfReader.
This class contains a single static function that retrieves a value from a configuration file, given a key:
public class ConfReader
public static String getValue(String key)
String val = null;
Configuration config = null;
config = new PropertiesConfiguration("src/main/config/conf.properties");
catch (ConfigurationException e)
if (config != null)
val = config.getString(key);
Apache commons-configuration is used in this example.
This module has also, a configuration file called conf.properties and it is located at src/main/config:
Now, let us say there is an application that is dependent on jar-with-conf called app-using-jar-with-conf (forgive the names I named - one of the toughest task in computer science, as someone once said). This is the simplest application:
public class UsingDepWithConf
public static void main( String args )
System.out.println("value of key1 is " + ConfReader.getValue("key1"));
System.out.println("value of key2 is " + ConfReader.getValue("key2"));
Of course, while running this simple main method, getValue() will fail as the configuration file is absent from the jar (we didn't put it under the resources directory).
In order to achieve the above requirements we will create a zip, containing the config directory and deploy it to a Maven repository. The client application will retrieve the zip and extract it to its own directory structure.
- Creating The Zip
We will use maven-assembly-plugin for the job. First let's create an assembly descriptor and call it zip.xml:
<assembly xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"In plain English we say here we want to create a zip file from the config directory. Next let's configure the pom.xml of jar-with-conf to use this descriptor:
<build>Which means, we want to create a single zip file during the package phase according to the zip.xml assembly file.
- Deploy The Zip
Of course, packing the config directory into a zip file will not suffice. There is no way client application can access it. That is exactly the reason we have Maven repositories. We will deploy the zip file alongside the module jar artifact. For that, I'll use maven-deploy-plugin. This plugin's deploy goal is bound when creating a jar artifact to the deploy phase in the default Maven lifecycle. Here, I am going to use a different goal - deploy-file which enables us the deployments of artifacts other than the default ones. Here is a snippet of the deployment task in the pom.xml:
<plugin>In the above snippet, the goal deploy-file is bound to the deploy phase, and in the configuration section, all the relevant information is supplied for successful deployment, like repositoryId (make sure it is configured in your settings.xml file and that you have permissions to deploy to the repository), repository URL and, of course, the new artifact identifier - the trinity of groupId, artifactId and version.
- Using The Jar with the Zip
Now, let's configure an application to be dependent on the jar-with-conf artifact and also retrieve the configuration folder and put it in the right place. The following are snippets from the pom.xml of the application app-using-jar-with-conf: The easy part is the artifact dependency:
<dependency>Next, let's retrieve the second artifact that contains the configuration:
<plugin>The details of this plugin can be found here. The result of this will be an unpacked config folder under src/main in the app-using-jar-with-conf project. The jar of jar-with-conf is in classpath and its configuration is available for change in the client application.
This kind of project setup encourages modularity in big systems. System architects should break the design into self-contained modules with simple and clear functionality and API. Those modules can serve whichever piece of software that is in need of such functionality.
Opinions expressed by DZone contributors are their own.