Apache Tamaya Proposal for Incubation

Abstract

Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design, which should provide a minimal but extendible modern and functional API leveraging SE, ME and EE environments.

Tamaya hereby translates into in the middle, which is exactly, what configuration should be. It should be in the middle between your code and your runtime.

NOTE: Alternative names could be Mahkah=earth, Dakota=friend or Orenda=magic force.

Proposal

Tamaya is a highly flexible configuration solution based on an modular, extensible and injectable key/value based design. The basic building block hereby are property providers implementing a small and easily implementable subset of a ´Map<String,String>´. This simplicity comes with a long list of decent advantages such as

Properties can be read from files, classpath resources, or any accessible URI in any format. Extensions (custom formats and resource locations) can be provided by according SPIs easily.

Additionally configuration providers can be implemented as environment aware, which allows to dynamically returns different configuration trees, based on the current runtime environment. Hereby the environment is as well based on a simple key/value model, which additionally supports child/parent relations between environments.

Finally with Configuration the API for configuration provides higher level features, such as type safe access and functional extension points, By default supporting all common data types from the Java platform, including a representation for configured collection data. Well defined extensions allow to adapt any target type required, as well as easily support more advanced features such as templates, secured views, multi-valued validation schemes, en-/decryption or other.

By default configuration (and property providers) are designed and implemented as indirectly mutable types, providing thread-safe, unsynchronized and therefore fast access to configuration. Mutabilty is ensured (if supported), by creation of a mutable builder using a final commit(). The API allows to listen to changes on a global as well as on a local, configuration based level. It is also planned to support remote configuration change propagation scenarios.

Overall the API should be easy to learn, with a minimal set of artifacts to be know by the developers. The API then can be implemented by different third parties using Tamaya's SPI. Tamaya itself will provide a lean, flexible, enterprise friendly implementation as well, with a minimal set of third party dependencies. If possible an implementation executable on Java ME should be provided as well.

Background

There is a global initiative running now for about a year lead by Anatole Tresch (Credit Suisse) with the target of standardizing configuration in Java EE and SE. Due to several reasons it seems currently most sensible to start an OSS project on the topic to join forces that actively want to contribute to the project. It is highly probably that standardization will be restarted at a later point. For further information you may look at his blog at javaeeconfig.blogspot.com .

Rationale

Configuration is one of the most cross-cutting concerns, which still lacks of any standard, especially beside Java EE. Nevertheless Java EE is currently (EE7) in most areas strictly only configurable during build time of the deployed artifacts. Especially dynamic provisioning of resources or runtime configuration is not supported and in many cases impossible to add without tweaking the underlying application server. On the other hand running two separate configuration solutions for Java EE and Java SE as well make no or little sense. So it would be important we have a unified configuration model at hand, that is flexible enough, so

Initial Goals

There is an existing code base implementing a significant part of the features mentioned already at https://github.com/java-config , which will be moved into the incubator. After having etablished the project infrastructure, it would be important to release an initial version soon, so we can ensure adoption is pushed quickly forward and the project's member can also bring in ideas and enhancement proposals to the current running Java EE 8 JSRs.

Current Status

There is an existing running code base implementing a significant part of the features mentioned already at https://github.com/java-config and licensed under Apache v2.0, which will be contributed into the incubator. The separation between API and implementation hereby should stay enforced, since

Meritocracy

We plan to do everything possible to encourage an environment that supports a meritocracy. We did the same as well with JSR 354, were people throughout the world helped us to get the RI/TCK at a very good level. Similarly, whenever possible, we encouraged people to join the expert group, so they also would be capable of contributing to the API directly. In all cases we discussed all questions amd feedback transparently regardless if it was an EG member or just a member of Hackday, Hackergarten.

Community

The project initiative already is significantly supported by JUGs such as SouJava, LJC, iJUG, Berlin Brandenburg JUG, JUG Zurich, as well as companies such as Credit Suisse and Walmart. It is expected that support will raise very quickly so the library will evolve and be widely used as well.

Core Developers

The core team will be a set of well known experts from the Java SE and EE area:

It is expected that more people will join the incubator once it's running:

Alignment

Credit Suisse, which lead the initiative through Anatole Tresch during the last year, has a strong commitment to Open Source Software. As a consequence also their first JSR (354, Money & Currency) was released under Apache v2. The same is the case for all other core contributors and supporters.

Known Risks

Main Risk could be that main committers could cease the project before it is possible to build up a public community. Nevertheless the wide support of JUGs and companies involved already as well as the engagement of main drivers of the initiatives during the last year makes this not a very probable scenario.

Orphaned products

See main risks. Basically the engagement of all stakeholders (Credit Suisse, JUGs, other companies) should ensure this initiative will evolve hopefully rather quickly to a key component in the Java eco-system, both in SE, as well as ME and EE. Additionally all stakeholders involved (companies, as well as individuals/JUGs) have direct benefits of the functionality provided.

Inexperience with Open Source

Starting point will be the experimental repository at https://github.com/java-config. Additionally the talks given by Anatole (e.g. at Javaone 2014) and the blogs under http://javaeeconfig.blogspot.com help to give a good starting point on some of the concepts implemented/contributed. Nevertheless the idea is that the ideas are further evolved, basically similar to a JSR, to ensure all relevant views and aspects will be included.

All of the core committers have already experience working on open source projects or JSRs. Many of them even already are members of the ASF.

Homogenous Developers

The current list of committers includes developers from several different companies plus many independent volunteers. The committers are geographically distributed across the U.S., Brazil, Europe, and Asia. They are experienced with working in a distributed environment.

Reliance on Salaried Developers

Some of the developers are paid partially by their employer to contribute to this project, but given the anticipation from the Java community for a powerful Configuration implementation and the committers' sense of ownership for the code, the project would continue without issue if no salaried developers contributed to the project. Anatole, as the main committer and driver of the initiative currently, is paid only partially and basically drives the initiative as part of his community engagement in general already as of now.

Relationships with Other Apache Products

The project's core API will be independent of any other projects, because

Tamaya will provide a minimal standalone implementation as well. Nevertheless it will be possible that other solutions implement the API as well, e.g. Apache Commons Configuration (especially version 2). The API/SPI should be build in a way, so features from other solutions such as

can be used or even be leveraged (e.g. by adding environment dependent configuration instance management).

Tamaya will also provide adapter modules for other technologies/projects, so the solution can inter-operate with existing frameworks and solutions as a provider similarly. This explicitly also includes the possibility to use Tamaya as a configuration/property source for.

Integration into Java EE has to be coordinated with Apache Deltaspike Configuration, to avoid two conflicting configuration standards for Java EE.

An Excessive Fascination with the Apache Brand

While we expect the Apache brand may help attract more contributors, our interests is in establishing a powerful and widely used standard for configuration. At a later stage, if successful, standardizing it within a JSR also may be an option. We believe this process starts with growing a strong and self-managed community that can someday lead the charge in any future standardization efforts. Furthermore, we have been enthusiastic users of Apache and feel honored at getting the opportunity to join and learn.

Documentation

References to further reading material.

Links to some other existing solutions:

Initial Source

Initial source will be from https://github.com/java-config . Most of the functionalities are already fully functional, documentation must be improved.

It is already licensed under Apache v2.

External Dependencies

The API part of the current initial source is completely standalone (it does not have any further dependencies than the JDK). The SE 8 based part does mainly depend on sl4j for logging and uses Weld SE for testing a possible CDI integration.

Cryptography

The framework will not bring along additional cryptographic algorithms.

Required Resources

Mailing lists

We initially would like to start with the minimum required lists:

Git Repository

The project will be hosted at https://git-wip-us.apache.org/repos/asf/incubator-tamaya.git

Issue Tracking

JIRA Tamaya (tamaya)

Other Resources

None.

Initial Committers

Affiliations

Sponsors

Champion:

Sponsors:

Nominated Mentors

Sponsoring Entity

Incubator

ProjectProposals/TamayaProposal (last edited 2014-11-05 17:25:32 by Anatole Tresch)