OpenCyclos/Cyclos database (Repost)

The work done so far on OpenCyclos has shown that upgrading the database layer to conform to the JPA standard as it is today will take a tremendous amount of resources. The best way to move forward is to use [login to view URL] and build a new database layer. This could be done either by continuing to develop the OpenCyclos codebase in one of it’s forms or to revert back to the Cyclos codebase and just replace the database layer, while leaving everything else as intact as possible. The new database layer must be: * RAD * Easy to create, update and maintain, * Secure using up to date JPA libraries. * Work with both OpenJPA and Hibernate. (Develop with OpenJPA and test with Hibernate) Meaning all dependencies directly on Hibernate must be removed * Well documented, which jeddict should provide out of the box. But you may need to add information on how this ties in to other application properties. * Redesigned to become cleaner and easier to create, update and maintain. A quick review of the database generated by the original code shows that quite a few tables can be eliminated and replaced with something more generic. There for example seems to be a few occurrences of tables that store specialized security access data, it is probably better simplify and push some of that to business logic. The new version of OpenCyclos must not: * Have secure new libraries in anything outside of the database layer. * Components other than the DB layer must not consume more time than necessary. Keep a is as much as possible but if rewriting something is faster – do that. * The API/RPC layer do not need to work, nor does the Android app. Remove them if necessary. We are probably going to rewrite both with very different technology. The RPC layer is way to much code and the app is ancient. * Other non-essential components may need to be removed in order to speed development up. * Other suggestions that speed up the development is welcome. Furthermore I want you to finish up with a brief evaluation of how to move forward. Rewriting components are not out of question and plans exist to rewrite the UI in Vaadin. However the extra load Vaadin puts on both client and server may make us consider other alternatives. Also our potential darknet users may be uncomfortable with the JavaScript dependencies in Vaadin as JavaScript are usually considered a great danger and get’s turned off.