Re: Maven based build and refactoring

On 3/25/12, Dave Cramer <pg(at)fastcrypt(dot)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(at)laliluna(dot)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(at)postgresql(dot)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*