Re: Maven based build and refactoring - Mailing list pgsql-jdbc
From | Atri Sharma |
---|---|
Subject | Re: Maven based build and refactoring |
Date | |
Msg-id | CAOeZVifOQasn8b3ekKEBP7Br=gJOFDTr_gS5im4E-OrV9Kq51A@mail.gmail.com Whole thread Raw |
In response to | Re: Maven based build and refactoring (Dave Cramer <pg@fastcrypt.com>) |
List | pgsql-jdbc |
On 3/25/12, Dave Cramer <pg@fastcrypt.com> wrote: > Dave Cramer > > dave.cramer(at)credativ(dot)ca > http://www.credativ.ca > > > > On Sun, Mar 25, 2012 at 12:16 PM, Sebastian Hennebrueder > <usenet@laliluna.de> wrote: >> Hello to all, >> >> actually I only wanted to have a look which JDBC 4 methods had been >> missing >> and provide a helping hand to implement those. >> >> The reason is that Hibernate requires now JDBC 4 and Hibernate is the >> underlying JPA provider in the JBoss application server as well. I prefer >> PostgreSQL over other open source database server, so JDBC 4 is an >> absolute >> requirement. > > What methods are missing that Hibernate actually uses ? >> >> I found the building mechanism a little bit special and played with >> refactoring the code such that a Maven build could work. > > What is wrong with using ant ? It is simple and it works. How does > maven improve this ? >> >> I split the code into common and jdbc version specific versions and found >> clean ways to solve the version, minor and major version infos, exception >> factories and logger control but reached now a point where the >> refactoring >> would require deeper code changes. >> >> Before I spent time doing this, I would like to know if there is any >> interest in this. > > I would need to be convinced. >> >> Here is my plan: >> >> separation of the projects into >> common (all which is not in the other packages) >> jdbc3 (contains generated classes) >> jdbc3g (contains generated classes) >> jdbc4 (contains generated classes + jdbc4 only code) >> common-test (all tests) >> >> Version information are loaded from property files which can be replaced >> during build time. The Driver delegates to a DriverVersion class in the >> common module which provides the version information. >> An exceptionFactory in the common module provides the "unimplemented" >> factory method for exceptions. >> >> As there are classes in common which references classes in jdbc(3 | 3G | >> 4) >> the code needs to be decoupled using interfaces. The lack of interfaces >> and >> the wildly use of inheritance instead of composition is the biggest >> obstacle >> to decouple modules. > > There is a very good reason for this. All of the various versions of > the driver use common routines to do the heavy lifting. This > guarantees that regardless of which version you are using it will be > well tested as the code path is more or less the same. > > Dave > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc > ----------------- Hi Dave/Sebastian, Sebastian:Thanks for the ideas.I'll keep them in mind. Dave:Can I start developing more on Sebastian's ideas,in addition to mine? Waiting for your reply, Atri -- Regards, Atri *l'apprenant*
pgsql-jdbc by date: