I'm agreeing with Rainer. I often debate with my colleagues of the achitecture 
unit about the benefits of Empire-db. Mostly they agree with me, but they also 
mention the lack of some features and integration with other frameworks. E.g. 
they're asking for Spring support (transaction management), caching 
possibilities or "Java-Object-Model" generators from existing database schema.

So, I think there are challenges awaiting the project. And only a powerful 
community around the Empire-db project can handle these challenges under the 
patronage of ASF.

Best regards,
Manuel Gamerdinger



-----Ursprüngliche Nachricht-----
Von: Rainer Döbele [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 26. Juni 2008 22:20
An: general@incubator.apache.org
Betreff: Re: [PROPOSAL] Empire-db


Referring to: http://wiki.apache.org/incubator/Empire-dbProposal

Martijn Dashorst wrote:
> I find this alarming: when there are no new challenges awaiting the 
> project, why join Apache? The code is stable and mature, you can just 
> leave it at sf.net. There doesn't seem to be a plan other than "let's 
> join Apache and hope the community grows automatically". If the 
> current core developers don't have challenges for the project, how 
> would the community grow?

I feel a little misunderstood here. Mature does not mean finished. We can think 
of a lot of improvements that we just did't have the demand for yet. And we 
cannot implement new features just for the sake of it. For example there are 
currently only four DBMS supported by Empire-db: Oracle, SQL-Server, MySQL and 
HSQLDB. We neither have the demand nor the expertise to support other systems, 
but other people might have. This is a good entry point for other developers to 
join in the development process. There is also demand for more in-depth work in 
the drivers e.g. to provide better support for stored procedures or DBMS 
specific features.

But most of all, we see Empire-db as more than just a DB layer. The true 
benefit comes from utilizing its metadata services in the presentation layer. 
With our Stuts2 extensions we show one possible solution how this can be 
achieved - limited to be used in conjunction with Struts2 of course. A similar 
thing can possibly be done for JSF, Wicket or others. And it's certainly also 
feasible for rich client user interfaces. This is not a trivial task and 
requires a sound understanding of the corresponding presentation layer 
framework. We can only provide the vision, but it takes some experts and a 
strong community to make it reality.

BTW: we are currently working on a new release that will allow the definition 
of metadata for non relational data objects like data from flat files or 
Web-Services in a similar manner in order to provide a uniform client level 
access for data and metadata. Any help with this is deeply appreciated.

> I'm not convinced yet that incubating at Apache is the best thing for 
> empire-db. I think that seeking out new ideas, users and (future) 
> committers for the project is the highest priority. Of course this can 
> be done whilest incubating, but having incubator plastered all over 
> the project won't attract more users or developers.
>
> Some mild marketing such as posting an article on javalobby
> (java.dzone.com) or theserverside.com to get some publicity will help 
> the project more than becoming an Apache project.

Posting articles on javalobby or theserverside.com is certainly a good idea. 
But isn't this another thing that a community is good for? I will certainly 
support anyone who is planning on doing so.

Overall I am not convinced that leaving he project on sf.net and writing a view 
articles will really bring the project forward. IMO the ASF is the right 
platform. But of course I respect your opinion.

Regards,
Rainer


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to