Re: JDBC3 Sugquestion - Mailing list pgsql-jdbc

----- Original Message -----
From: "Barry Lind" <barry@xythos.com>
To: "Ian Brandt" <ian@ianbrandt.com>
Cc: "PostgreSQL JDBC" <pgsql-jdbc@postgresql.org>
Sent: Monday, February 18, 2002 12:53 PM
Subject: Re: [JDBC] JDBC3 Sugquestion


> Ian,
>
> There are three reasons why I think what you are suggesting doesn't work
> as well as some other suggestions that have been made.
>
> 1)  Your proposal essentially creates three distinct copies of the code,
> one in each of three cvs branches.  This means that when a bug needs to
> be fixed, then the same fix needs to be done three times.  What is
> really desired is a good OO way of encapsulating the common code and
> having differences only where necessary.

Sorry, I've been using SCCS for the past three years, and I mixed up my CVS
terminology.  I meant to say "tag" instead of "branch".  Creating copies of
the code is exactly what I was hoping could be avoided.  Instead
JDBC1,2,3,etc. would be handled by making successive releases of the same
code.  And again bug fixes would be done in the lowest applicable revision,
and merged forward as appropriate.  Hopefully this clears things up a good
bit?

Ian



> 2)  How would the source code under your proposal be bundled?  Given
> that source code for open source software if very important, how would
> the pgsql-src.tar.gz file be produced?  It seems difficult to get files
> from multiple different branches but with the same names pulled and
> built into a common source distribution.
>
> 3)  How would you suggest branches on these branches be done?  For
> example now that 7.3 development is opened up, there is a 7.2 branch on
> the source to facilitate bugs going into 7.2.x.  How would you suggest
> these release branches be layered on top of your proposed branches
> without causing too much confusion?
>
> thanks,
> --Barry
>
>
> Ian Brandt wrote:
> > Hi,
> >
> > I am interested in JDBC3 support for PostgreSQL.  I was going through
the
> > archived posts with regard to this, and have a half suggestion, half
> > question (hence the new word I just made up in the subject)...
> >
> > Instead of the previously suggested code forking, build process
changing,
> > and RTTI related ideas, would it be possible to address the problem of
> > supporting multiple JDBC versions with source control?  Here's a rough
idea
> > of how this might work (born out of much ignorance with regard to your
> > development practices!)...
> >
> > Create a new CVS repository for JDBC.  Take the existing code, extract
and
> > rework everything such as to make a JDBC1 compliant implementation.
This
> > would involve some re-packaging.  Everything JDBC related that is
currently
> > under org.postgresql would be moved one level deeper to
org.postgresql.jdbc,
> > except for the stuff currently under org.postgresql.jdbc1, which would
be
> > moved/merged to also be in org.postgresql.jdbc.  Once everything is
reworked
> > and checked in, create a jdbc1 branch.  Then take the stuff currently in
the
> > org.postgresql.jdbc2 package, and rework that into org.postgresql.jdbc
in
> > this new repository as well, so to have a JDBC2 compliant
implementation.
> > Create a jdbc2 branch.
> >
> > Updating to JDBC3,4,etc. would then involve updating the existing code
to be
> > compliant, and creating a new branch.  The driver would be distributed
as
> > pgjdbc1.jar, pgjdbc2.jar, etc. simply by checking out the corresponding
> > branch, building under the appropriate jdk, and jar'ing it up.  Bug
fixes
> > could be done in the lowest appropriate branch, and merged forward as
> > appropriate.
> >
> > As far as users are concerned, having to use the different jar and
classpath
> > based on the JDK/JDBC version they desire to use shouldn't be an issue.
> > This is very commonplace for such things.
> >
> > So I hope this idea isn't totally out in left field!  Either way I look
> > forward to JDBC3 support.
> >
> > Thanks,
> >
> > Ian
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> >
> >
>
>
>