incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henning Schmiedehausen <henn...@apache.org>
Subject Re: [VOTE] Accept Empire-db for Incubation
Date Mon, 30 Jun 2008 20:35:02 GMT
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message