incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <>
Subject [VOTE] Accept Empire-db for Incubation
Date Mon, 30 Jun 2008 20:32:40 GMT
This vote will run until Monday, July 7th, 2008.

[ ] +1 Accept Empire-DB for incubation
[ ]  0 Don't care
[ ] -1 Reject for the following reason:

= Empire-db Proposal =

This proposal is an application for the Empire-db Open Source
component to become a new top-level project within the Apache Software
Foundation. It is our desire to open Empire-db to a wider audience in
order to build up a larger and more diverse community with a high
level of collaboration.

== Rationale ==

Empire-db is a lightweight relational database access layer that is
significantly different from other ORM or Data Mapping solutions.  At
its core, Empire-db uses a Java Object Model to describe the physical
data model rather than XML or annotations which leads to the following

 * An intuitive command API allows dynamic generation of select,
   update, insert or delete SQL-statements of any complexity exactly
   as desired. The SQL statements are created purely by using Java
   methods which reference the model objects (like columns, tables,
   views, etc.). This provides type-safety and entirely eliminates the
   use of string literals for names or expressions in
   code. Additionally DBMS independence is achieved through a
   pluggable driver model.

 * The object model also provides safe and easy access to
   meta-information of the data model such as field data type, maximum
   field length, whether a field is mandatory and a finite choice of
   options for a field’s values. Metadata is user-extensible and not
   limited to DBMS related metadata. Availability of meta-information
   encourages more generic code and eliminates redundancies throughout
   application layers.

 * Using references to table and column objects significantly improves
   compile-time safety and thus reduces the amount of testing. As a
   positive side effect the IDE’s code completion can be used to
   browse the data model, increases productivity and eliminates the
   need for other external tools or IDE-plugins.  Empire-db is not a
   traditional OR-Mapper as it does not use traditional Beans / POJO’s
   representing full database entities. Instead database entities are
   usually handled by dynamic “Record”-objects with support for
   identity management and optimistic locking. This makes it even
   possible to change the data model at runtime. Optionally data
   retrieval with POJO’s is also supported.  With its approach we
   believe that Empire-db would complement the other relational
   database access solutions at Apache and be an enrichment for the
   platform and all its users.

=== Criteria ===

==== Meritocracy: ====

We are committed to actively encourage talented members of the
community to participate and contribute to the project in order to
support an Apache style meritocracy.

==== Community: ====

Currently there is only a small community based around the core
developers. But even though there are many other solutions in the area
of relational database access including several Apache projects, we
believe that benefits from the alternative approach taken by Empire-db
provides the potential to attract a large community, which we are
hoping to develop during incubation.

==== Core Developers: ====

The community currently consists of the following 4 

 * Rainer Döbele (ESTEAM Software)
 * Matthew Bond (ESTEAM Software)
 * Jörg Reiher (ESTEAM Software)
 * Manuel Gamerdinger (T-Systems)

==== Alignment: ====

Empire-db’s metadata management features make it possible to achieve a
high level of integration with existing presentation layer frameworks,
which leads to reduced redundancies as well as a better separation of
model and view compared to other approaches.  With our
Empire-Struts2-Extensions subproject we offer such an implementation
for the Apache Struts2 web application framework project that acts as
the glue between presentation and business / persistence layer.  We
would like to see further integration efforts for other presentation
layers evolve in further subprojects.

=== Known Risks ===

==== Orphaned products: ====

All current developers are committed to continue their work hence
there is little risk of the project being orphaned.

==== Inexperience with Open Source: ====

Empire-db has been Open Source from its start in 2001, but it has only
been publicly available since January 2008. All committers have long
experience in using Open Source projects, but none has served as a
committer on other Apache projects. We do, however, not expect any
difficulty in adapting the Apace development process and follow the
meritocracy rules.

==== Homogenous developers: ====

All core developers have initially worked for the same employer, with
one now working for a different employer at a different location. It
is one of our primary goals to become a more heterogeneous community.

==== Reliance on Salaried Developers: ====

The development of Empire-db was fuelled in the past by the
requirements of professionally developed applications. None of the
developers were paid solely for developing, maintaining or monitoring
the project and a lot of work has been done on a voluntary basis.

==== Relationships with Other Apache Products: ====

Empire-db itself uses some Commons projects and Log4j.

The Empire-Struts2-Extensions subproject offers a special high level
integration with the Apache Struts2 web application framework that
delivers compile-time-safety and metadata access to the presentation

In comparison to other relational data access projects at Apache
Empire-db is probably somewhere between the OR-Mappers (Cayenne,
OpenJPA, Torque) and iBATIS. Unlike the OR-Mappers Empire-db is a not
hiding away data access SQL statements from the developer but allows
the developer to control every aspect of an SQL statement and its
execution. And unlike iBATIS the SQL statements are not provided as
string literals but are generated from a command object for the
selected target DBMS. This leads to particular benefits when
statements need to be generated conditionally with varying column
selection and / or row filter criteria.

==== A Excessive Fascination with the Apache Brand: ====

We believe that one of the biggest advantages of the ASF is the
provision of variety and choice. With Empire-db there is a remarkably
different solution for a very common task that we think fits in very
well with other existing database access layer projects allowing
developers to choose the best solution for their needs. Even though
Empire-db could exist on its own, as an Apache project it will
certainly benefit from increased visibility as well as the friendly
competition with other projects such as Cayenne, OpenJPA and iBATIS.

=== Documentation ===

Comprehensive information and documentation can be found on

== 1. Scope of the project ==

The project consists of a core component which contains the data
access layer.

It is planned to create further subprojects with integration code for
different presentation layer frameworks in order to fully benefit from
empire-db’s metadata management features. Currently there is one such
project for the Apache Struts2 web framework called

== 2. Initial Source from which the project is to be populated ==

Current Empire-db sources can be found here:

Sources for the Empire-Struts2-Extentions can be found here:

== 3. Identify the ASF resources to be created ==

=== 3.1 Mailing Lists ===

 * empire-db-dev
 * empire-db-user
 * empire-db-scm
 * empire-db-ppmc

=== 3.2 SVN Repositories ===

 * /incubator/empire-db

=== 3.3 Issue Tracking ===

 * Need a new Jira project called empire-db.

== 4. Identify the initial set of committers ==

 * Rainer Döbele
 * Matthew Bond
 * Jörg Reiher
 * Manuel Gamerdinger
 * Henning Schmiedehausen
 * Thomas Fischer
 * Martijn Dashorst

== 5. Identify Apache sponsoring individual ==

We kindly request the Apache Incubator PMC to be the sponsor for this

=== Champion and Mentor ===

Henning Schmiedehausen (henning _at_

=== Mentors ===

 * Thomas Fischer (tfischer _at_
 * Martijn Dashorst (martijn.dashorst _at_
 * Henning Schmiedehausen (henning _at_

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message