Quantcast

Maven based build and refactoring

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Maven based build and refactoring

Sebastian Hennebrueder
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.

I found the building mechanism a little bit special and played with refactoring the code such that a Maven build could work.

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.

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.
This is the bigger change, I am about to do. 

I would introduce a Service registry, which can create providers for various interfaces. The driver could register on start up (static block) . Here is a conceptual piece of code:

class ServiceRegistry{
 static Map<Class,Provider> interfaceProviderMap
public static Provider getProvider(Class aClass){ … }
}

The code in the class PGObjectFactory in the method could then be changed from

private Object loadSimpleDataSource(Reference ref)
    {
        PGSimpleDataSource ds = new PGSimpleDataSource();
        return loadBaseDataSource(ds, ref);
    }

to
private Object loadSimpleDataSource(Reference ref)
    {
Provider provider = ServiceRegistry.getProvider(PGSimpleDataSourceInterface.class);
        PGSimpleDataSourceInterface ds = provider.create();
        return loadBaseDataSource(ds, ref);
    }


-- 
Best Regards / Viele Grüße

Sebastian Hennebrueder

-----
http://www.laliluna.de
Java software developer and trainer for Hibernate and Java Persistence

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Atri Sharma

 

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Sebastian Hennebrueder
Sent: 25 March 2012 21:47
To: [hidden email]
Subject: [JDBC] Maven based build and refactoring

 

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.

 

I found the building mechanism a little bit special and played with refactoring the code such that a Maven build could work.

 

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.

 

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.

This is the bigger change, I am about to do. 

 

I would introduce a Service registry, which can create providers for various interfaces. The driver could register on start up (static block) . Here is a conceptual piece of code:

 

class ServiceRegistry{

 static Map<Class,Provider> interfaceProviderMap

public static Provider getProvider(Class aClass){ … }

}

 

The code in the class PGObjectFactory in the method could then be changed from

 

private Object loadSimpleDataSource(Reference ref)

    {

        PGSimpleDataSource ds = new PGSimpleDataSource();

        return loadBaseDataSource(ds, ref);

    }

 

to

private Object loadSimpleDataSource(Reference ref)

    {

            Provider provider = ServiceRegistry.getProvider(PGSimpleDataSourceInterface.class);

        PGSimpleDataSourceInterface ds = provider.create();

        return loadBaseDataSource(ds, ref);

    }

 

 

-- 
Best Regards / Viele Grüße

Sebastian Hennebrueder
----------------------

Hi Sebastian,

 

I am a student and I am planning to work on implementing the missing parts of JDBC 4 as my GSoc 2012 project.I have already started discussing with Dave Krammer for this.

 

It would be really helpful for me if senior hackers like yourself can assist me in this ambitious project of mine.

 

Regards,

 

Atri

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Dave Cramer-8
In reply to this post by Sebastian Hennebrueder
Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca



On Sun, Mar 25, 2012 at 12:16 PM, Sebastian Hennebrueder
<[hidden email]> 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 ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Atri Sharma
On 3/25/12, Dave Cramer <[hidden email]> wrote:

> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
>
> On Sun, Mar 25, 2012 at 12:16 PM, Sebastian Hennebrueder
> <[hidden email]> 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 ([hidden email])
> 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*

--
Sent via pgsql-jdbc mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Sebastian Hennebrueder
In reply to this post by Dave Cramer-8


Am 26.03.2012 um 00:39 schrieb Dave Cramer:

> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
>
> On Sun, Mar 25, 2012 at 12:16 PM, Sebastian Hennebrueder
> <[hidden email]> 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 ?

At least I am aware of createBlob/Clob but I haven't done a complete check.

>>
>> 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 ?

Maven repositories as a common way to store open source artifacts and is easier to manage using Maven.
Maven build projects can be easily imported into any IDE (Eclipse, Netbeans, IntelliJ)
If I want to work on the project, I can be up an running in seconds by checking out and importing a Maven project into my IDE without the need to understand the details of a Ant build and excluding paths to be considered as source code.

>>
>> 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.

I will try my best ;-), see below



>>
>> 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.

I agree with reusing the same code for various pieces but this does not require the approach used. Common code can still reside int the common module but the jdbc version specific code can be put into a dedicated project. The fact that a PGPooledconnection extends a AbstractJDBC4* class and a AbstractJDBC3* class is version specific for example.

Introducing interfaces just disconnects from the implementation and as a consequence shared code needs no longer be aware of the implementation. If it asks the service registry for a factory (or service provider) to create a pooled connection it will get a jdbc4 pooled connection if it is a jdbc4 driver. This is more a technical consequence as the common module has no dependency on the jdbc specific project.

This allows to avoid  using a script to change parent classes in existing classes. An approach which makes it more difficult to refactor code as the changes cannot be applied to all jdbc versions in parallel. I assume that you have to switch between versions while being coding and reply refactorings as well to the *in Files, as they are not done by the IDE.

A final advantage is that we can compile the different modules with different Java versions and this can be done in your IDE as well.  You can use Java version specific language changes which is probably latest required with Java 8 and the new date API.


>
> Dave
>
> --
> Sent via pgsql-jdbc mailing list ([hidden email])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc


--
Sent via pgsql-jdbc mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Lew-23
Sebastian Hennebrueder wrote:
> Maven repositories as a common way to store open source artifacts

as are Ant-based projects

> and is easier to manage using Maven.

Depends.

I've seen Maven projects that were a complete cock-up to manage.

Ant or Maven, the biggest issues I've encountered involved obfuscation of
dependency chains.

> Maven build projects can be easily imported into any IDE (Eclipse, Netbeans, IntelliJ)

As can Ant-based projects.

> If I want to work on the project, I can be up an running in seconds by checking out and importing a Maven project into my IDE

Ditto Ant-based.

> without the need to understand the details of a Ant build

I am always deeply dubious of any argument that touts "without the need to
understand" as a virtue. This dubiety has yet to disappoint.

>and excluding paths to be considered as source code.

Sorry, but that is necessary to Maven-based projects, too.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--
Sent via pgsql-jdbc mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Sebastian Hennebrueder
Hello,

I can understand your points  and will put the refactoring idea aside but do what I originally wanted - help with the missing JDBC 4 things.

-- 
Best Regards / Viele Grüße

Sebastian Hennebrueder

-----
http://www.laliluna.de
Java software developer and trainer for Hibernate and Java Persistence

Am 28.03.2012 um 06:54 schrieb Lew:

Sebastian Hennebrueder wrote:
Maven repositories as a common way to store open source artifacts

as are Ant-based projects

and is easier to manage using Maven.

Depends.

I've seen Maven projects that were a complete cock-up to manage.

Ant or Maven, the biggest issues I've encountered involved obfuscation of dependency chains.

Maven build projects can be easily imported into any IDE (Eclipse, Netbeans, IntelliJ)

As can Ant-based projects.

If I want to work on the project, I can be up an running in seconds by checking out and importing a Maven project into my IDE

Ditto Ant-based.

without the need to understand the details of a Ant build

I am always deeply dubious of any argument that touts "without the need to understand" as a virtue. This dubiety has yet to disappoint.

and excluding paths to be considered as source code.

Sorry, but that is necessary to Maven-based projects, too.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

--
Sent via pgsql-jdbc mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Maven based build and refactoring

Dave Cramer-8
That would be awesome!

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca



On Wed, Mar 28, 2012 at 2:12 PM, Sebastian Hennebrueder
<[hidden email]> wrote:

> Hello,
>
> I can understand your points  and will put the refactoring idea aside but do
> what I originally wanted - help with the missing JDBC 4 things.
>
> --
> Best Regards / Viele Grüße
>
> Sebastian Hennebrueder
>
> -----
> http://www.laliluna.de
> Java software developer and trainer for Hibernate and Java Persistence
>
> Am 28.03.2012 um 06:54 schrieb Lew:
>
> Sebastian Hennebrueder wrote:
>
> Maven repositories as a common way to store open source artifacts
>
>
> as are Ant-based projects
>
> and is easier to manage using Maven.
>
>
> Depends.
>
> I've seen Maven projects that were a complete cock-up to manage.
>
> Ant or Maven, the biggest issues I've encountered involved obfuscation of
> dependency chains.
>
> Maven build projects can be easily imported into any IDE (Eclipse, Netbeans,
> IntelliJ)
>
>
> As can Ant-based projects.
>
> If I want to work on the project, I can be up an running in seconds by
> checking out and importing a Maven project into my IDE
>
>
> Ditto Ant-based.
>
> without the need to understand the details of a Ant build
>
>
> I am always deeply dubious of any argument that touts "without the need to
> understand" as a virtue. This dubiety has yet to disappoint.
>
> and excluding paths to be considered as source code.
>
>
> Sorry, but that is necessary to Maven-based projects, too.
>
> --
> Lew
> Honi soit qui mal y pense.
> http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
>
> --
> Sent via pgsql-jdbc mailing list ([hidden email])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>

--
Sent via pgsql-jdbc mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Loading...