You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Henning Schmiedehausen <he...@apache.org> on 2008/06/30 22:32:40 UTC
[VOTE] Accept Empire-db for Incubation
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
Re: [VOTE] Accept Empire-db for Incubation
Posted by Eelco Hillenius <ee...@gmail.com>.
[ x ] +1 Accept Empire-DB for incubation
[ ] 0 Don't care
[ ] -1 Reject for the following reason:
I sympathize with Martijn's hesitations. However, incubation is a
try-out period, so if the Empire-DB people think they can build a
functioning community during their incubation, I'd say go for it :-)
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Accept Empire-db for Incubation
Posted by Henning Schmiedehausen <he...@apache.org>.
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
Re: [VOTE] Accept Empire-db for Incubation
Posted by Martijn Dashorst <ma...@gmail.com>.
+1
On Mon, Jun 30, 2008 at 11:49 PM, Craig L Russell <Cr...@sun.com> wrote:
> +1
>
> There are never enough open source persistence solutions.
>
> Craig
>
> On Jun 30, 2008, at 1:32 PM, 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 =
>
> Craig L Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: [VOTE] Accept Empire-db for Incubation
Posted by Craig L Russell <Cr...@Sun.COM>.
+1
There are never enough open source persistence solutions.
Craig
On Jun 30, 2008, at 1:32 PM, 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 =
Craig L Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [VOTE] Accept Empire-db for Incubation
Posted by Henning Schmiedehausen <he...@apache.org>.
And the results:
+1:
Craig L Russell <Cr...@Sun.COM> (*)
Martijn Dashorst <ma...@gmail.com> (*)
Niall Pemberton <ni...@gmail.com> (*)
Eelco Hillenius <ee...@gmail.com>
Henning Schmiedehausen <he...@apache.org> (*)
0:
none
-1:
none
(*) = Incubator PMC member.
Congratulations to the Empire-db team, you have been accepted to the
Incubator as a podling.
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
Re: [VOTE] Accept Empire-db for Incubation
Posted by Niall Pemberton <ni...@gmail.com>.
[X] +1 Accept Empire-DB for incubation
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
[RESULT] Re: [VOTE] Accept Empire-db for Incubation
Posted by Henning Schmiedehausen <hp...@intermeta.de>.
[ Whoops, once again with the right subject line to wake up people with
mail filters. :-) ]
And the results:
+1:
Craig L Russell <Cr...@Sun.COM> (*)
Martijn Dashorst <ma...@gmail.com> (*)
Niall Pemberton <ni...@gmail.com> (*)
Eelco Hillenius <ee...@gmail.com>
Henning Schmiedehausen <he...@apache.org> (*)
0:
none
-1:
none
(*) = Incubator PMC member.
Congratulations to the Empire-db team, you have been accepted to the
Incubator as a podling.
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
>
--
Henning P. Schmiedehausen -- hps@intermeta.de | 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org