Modules
smartics-properties is defined by a couple of individual modules. On this page we will introduce the main modules to let you know, which one are relevant in which use cases.
User Use Cases
Users are application or library developers who want to use smartics-properties as a library.
Users are mainly concerned with annotations. Here you annotate your properties to enforce e.g. validation or encryption.
For the task of integration smartics-properties into your project, you may want to consult a small part of the configuration module and some of the extension modules.
For reporting the recommended tool is a Maven plugin.
Implementor Use Cases
Implementors provide implementations for SPI provided by smartics-properties. For instance a company may want to access a currently unsupported database product to store property definitions. By implementing an SPI the new database product can be used with smartics-properties.
Implementors may refer to the configuration module and some of the extension modules for examples.
Core Modules
The core modules form the backbone of the library and provide interfaces to plugin extensions.
Annotations
First have a look at the annotations module to learn how to declare properties for your project.
The Annotations Tutorial provides a short introduction to this topic.
Core
The core module is the basic implementation to deal with properties. Users, that is developers that declare and use defined properties, usually do not get in touch with any of these classes.
Usually as a library user you want to skip this.
Resource
The resource module defines the interface for the core to access properties metadata. Implementations to this interface are provides as resource extensions.
Usually as a library user you want to skip this.
Report
The report module is a simple library to make report generation easier. Currently we only provide a Maven plugin that makes use of this library. If you plan to implement a report generator on your own, you may find some useful helpers here.
Usually as a library user you want to skip this.
Config
The config module provides access to properties configurations. While the core modules define property sets that are neutral to the environment, a configuration associates properties with an environment. So this module allows to select a configuration for a given environment by a configuration key.
Library users have to select an implementation to access property sets through the property declaring interfaces of their application. If there is an integration module selected (such as integration-cdi), the library user will only touch a couple of interfaces and not deal with configurations at all.
Extensions
The core modules specify some interfaces to provide implementations via the Java Service API.
Security Extensions
The following extensions provide implementations to secure property values. If a library user does not configure an extension explicitly, the system chooses a default implementation. Please refer to the Encryption Tutorial for details.
The following implementation may serve as an example how to interface with smartics-properties to provide your own adapter to a security library that meets your requirements.
Transfer Extensions
Transfer extensions allow to transfer property definitions to a target technology. If for instance you edit your properties as properties files in a SCM system, you may want to export these files to your JDBC database in your production environment.
- filesystem - transfer property definitions to a filesystem
- JDBC - transfer property definitions to a database via JDBC.
- Templatestream - create scripts based on templates to run these scripts on the target environment. For instance you may create SQL scripts to fill SQL databases in the target environment.
Integration Extensions
Integration extensions allow to integrate smartics-properties with injection technologies. So these extensions make accessing of configuration instances, property sets or even single property values more convenient for the library user.
Currently smartics-properties only uses the Java Service API internally to access the implementations of its interfaces.
- CDI - support to inject instances via CDI
Stores
This section provides information about stores that actually store property definitions physically.
Classpath
There is no special implementation to find property definitions on the classpath. The config modules provides this support out-of-the-box.
SQL Data Sources
Properties may be storied in SQL tables. The following databases are supported and may work as examples to add support for additional database products.
Please note that an implementation usually has to provide more than simple key/value store facility. In an environment usually different configuration are accessible. So to locate a property value the configuration key and the property key has to be passed to the store.