Yes, it's nice to have some O/R mapper in there as well --- so long as we expose DataSource, people who want to use other abstractions can still use them.
My only concern is that bundling JPA API classes might collide with some application servers, and end up breaking implementations that we bundle. 2012/12/8 Ben Castellucci <[email protected]> > Quick throw out here - how about JPA? Pretty DB-independent and can > provide its own schema creation scripts and such. > > Not sure about sync-ing over time. > > Maybe Apache's implementation (OpenJPA) for a friendly license? > > Would keep plugin developers away from writing SQL (it's just POJOs) and > let them choose their target DB vendor, even change it later. > > http://openjpa.apache.org/ > > Again, just a thought. > > Thanks, > Ben > On Dec 8, 2012 11:42 AM, "Vojtech Juranek" <[email protected]> wrote: > >> >> > Any suggestion for abstraction improvements before I release the >> > first version of the plugin? >> >> is limitation to SQL databases intentional? >> Personally I would add one abstraction layer, keeping hostname, >> credentials >> etc. in AbstractRemoteDatabase and moving SQL related stuff like >> DataSource in >> AbstractRemoteSqlDatabase which would inherit from AbstractRemoteDatabase >> >> -- Kohsuke Kawaguchi
