Re: JDBC split and move ... - Mailing list pgsql-jdbc
From | Barry Lind |
---|---|
Subject | Re: JDBC split and move ... |
Date | |
Msg-id | 3C674724.4070509@xythos.com Whole thread Raw |
In response to | Re: JDBC split and move ... ("Marc G. Fournier" <scrappy@hub.org>) |
Responses |
Re: JDBC split and move ...
(Peter Eisentraut <peter_e@gmx.net>)
Re: JDBC split and move ... (Bruce Momjian <pgman@candle.pha.pa.us>) |
List | pgsql-jdbc |
Marc G. Fournier wrote > > and this is one of the key reasons why -core started to go down > this route ... there are several *good* projects that are independent of > the backend whose release cycles are tied inot the backends release cycle, > but that *aren't* keyed to it ... > I meant to make a comment on this in my last mail note. It isn't true that jdbc is independent of the backend release cycle. In the last two releases that I have been involved in there have been changes in the backend that have required changes to jdbc. Thus a new jdbc release has been necessary for both 7.1 and 7.2. (generally this is due to changes in the core pg_* tables). In the current environment there isn't any reason that we couldn't already have more frequent releases of jdbc than the backend. But there are reasons why I beleive that at a minimum a new release of jdbc needs to correspond to each new server release. It seems to me that there are two reasons this whole proposal is being discussed: 1) More frequent releases for jdbc 2) Smaller more modular source bundles I would argue 1 can be achieved today without any changes. I feel that 2 is the issue that is really driving this discussion. Couldn't this be achieved in some other way, without the complete separation that is being suggested? Wouldn't it be possible to have a cvs structure that looked something like this: pgsql - server - jdbc - odbc - etc server - symlink to pgsql/server jdbc - symlink to pgsql/jdbc odbc - symlink to pgsql/odbc ... Where pgsql, server, jdbc, odbc would each then be a module that could be checkedout via cvs. So if you wanted everything you would just pull from pgsql (cvs checkout pgsql), or you could just pull jdbc (cvs checkout jdbc). I haven't thought about how configure would work in this environment, but I would think that there would be a top level configure at the pgsql level that would have options like --with-java, --with-server, etc, while each individual component would have it's own configure??? not sure here. As I stated before there are benefits of having a consolidated source tree (documentation, binary distributions, testing) that I am reluctant to give up just to achieve a smaller source bundle. thanks, --Barry
pgsql-jdbc by date: