Re: JDBC split and move ...

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