Installation

OWNER is a Java library. The distribution form is a JAR file.

However OWNER is available on Maven Central Repository, this means that if you want you can still download the library jar, the javadoc.jar, the sources.jar or a prepackaged archive containing the distributable binaries (including sources and javadocs) in bin.tar.bz2 or bin.tar.gz or bin.zip format from this link.

Once downloaded what you need, you are ready to configure your IDE; and here, it’s up to you and your chosen IDE. Generally speaking you just need to reference the library jar in the CLASSPATH environment variable, as explained in the Java tutorial.

Maven

If you are using Maven, things are quite simple, just add the following section to your pom.xml:

<dependencies>
    <dependency>
        <groupId>org.aeonbits.owner</groupId>
        <artifactId>owner</artifactId>
        <version>1.0.12</version>
    </dependency>
</dependencies>

Replace 1.0.12 with the latest version available. At the time of writing this page, the latest version is 1.0.12, but you need to check if there is any newer version.

Finding the latest version released

You can search on the Maven Central Repository to verify the latest available release.

Many modern IDEs integrate well with maven, so after adding the above section in your pom file and refreshing your project in your IDE, you should be ready to use the library APIs.

The formats that are not in the core

Since 2.0.0. Properties, XML, .env and INI are read by the owner artifact itself. The formats OWNER parses with a parser of its own live in owner-formats:

<dependency>
    <groupId>org.aeonbits.owner</groupId>
    <artifactId>owner-formats</artifactId>
    <version>2.0.0</version>
</dependency>

Adding it is all there is to do: each loader declares itself, so the format is read as soon as the artifact is on the class path — no registration, no line of code. See File formats for what it reads and Loading strategies for how it is found.

Why a separate artifact.

The core ships the formats the JDK can already parse: Properties reads properties, SAX reads XML, and .env and INI are line-by-line variations on the first. A parser we write ourselves is different in kind — it is code that chews on untrusted input, and a defect in one would be a security release for everybody, including the majority who never load that format. In its own artifact it reaches the people who asked for it, and can be fixed and released on its own.

It brings no dependency of its own either: the parsers are ours.

Java 8 and superior

Java 8 language features, such as default methods in interfaces, are fully supported by the owner artifact itself: no additional dependency is needed.

Older versions of the library shipped this support in a separate owner-java8 artifact, since the core had to run on Java 6/7. That artifact is no longer needed nor published: if you have it in your dependencies, just replace it with owner.

No transitive dependencies, full freedom!

The OWNER library does not introduce any transitive dependency to third party libraries into your project, so this should prevent any conflict with libraries from which your project depends on.

On the module path

Since 2.0.0.

The jars declare the name they take as automatic modules, so a requires written against them keeps resolving from one release to the next:

module com.example.myapp {
    requires org.aeonbits.owner;
}

Artifact	Module name
owner	org.aeonbits.owner
owner-extras	org.aeonbits.owner.extras
owner-formats	org.aeonbits.owner.formats

The name matters because without it the module system derives one from the file name, which carries the version: a requires written against owner-2.0.0.jar would stop resolving against the next release. Declaring it pins the name to the artifact instead, and it is the same name the OSGi bundle already had.

Both artifacts can be placed on the module path together, since they share no package: up to 1.0.12 the ZooKeeperLoader of owner-extras lived under org.aeonbits.owner.loaders, which the core also fills, and a package cannot belong to two modules.

Automatic modules, not explicit ones

The jars declare a name, they do not yet carry a module-info: OWNER is compiled for Java 8. An automatic module reads every other module and exports all of its packages, so the arrangement above is what makes the library usable on the module path, not a full modularisation of it.

Building from the sources

You can install the version under development to get advantage of the latest features.

If you want to do so, please consult the chapter Building from sources.