incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <>
Subject [PROPOSAL] Empire-db
Date Mon, 23 Jun 2008 15:49:57 GMT
Please see also

Comments until End of the week, if nothing blocking comes up, I intend
to CfV on Monday 30.6.08

--- cut ---

= 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

== 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
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
to attract a large community, which we are hoping to develop during

==== 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
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

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 ===

=== 3.2 SVN Repositories ===

=== 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_

--- cut ---

Henning P. Schmiedehausen  -- | JEE, Linux, Unix
91054 Buckenhof, Germany   -- +49 9131 506540  | Apache Java Software
Open Source Consulting, Development, Design    | 

INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB 7350
Gesellschaftssitz: Buckenhof. Geschaeftsfuehrer: Henning Schmiedehausen

  char name_buf[257];           /* max unix filename is 256, right? */

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

View raw message