Re: Maven based build and refactoring - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: Maven based build and refactoring |
Date | |
Msg-id | CADK3HH+Zax2bHfUuVQzLYk_w8LWwMTjYFOBekY2X1x1-BkMMTQ@mail.gmail.com Whole thread Raw |
In response to | Maven based build and refactoring (Sebastian Hennebrueder <usenet@laliluna.de>) |
Responses |
Re: Maven based build and refactoring
(Atri Sharma <atri.jiit@gmail.com>)
Re: Maven based build and refactoring (Sebastian Hennebrueder <usenet@laliluna.de>) |
List | pgsql-jdbc |
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
pgsql-jdbc by date: