Oh, and obviously I vote +1. :-)
Ciao
Henning
On Mon, 2008-06-30 at 22:32 +0200, Henning Schmiedehausen wrote:
> 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
> benefits:
>
> * 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
> developers:
>
> * 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
> layer.
>
> 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
> http://www.empire-db.org
>
> == 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
> Empire-Stuts2-Exentions.
>
> == 2. Initial Source from which the project is to be populated ==
>
> Current Empire-db sources can be found here:
> http://heanet.dl.sourceforge.net/sourceforge/empire-db/empire-db-2.0.1.zip
>
> Sources for the Empire-Struts2-Extentions can be found here:
> http://heanet.dl.sourceforge.net/sourceforge/empire-db/empire-struts2-ext-1.0.1.zip
>
> == 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
> project.
>
> === Champion and Mentor ===
>
> Henning Schmiedehausen (henning _at_ apache.org)
>
> === Mentors ===
>
> * Thomas Fischer (tfischer _at_ apache.org)
> * Martijn Dashorst (martijn.dashorst _at_ gmail.com)
> * Henning Schmiedehausen (henning _at_ apache.org)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
